Khi triển khai hệ thống quản lý rework trong ngành sản xuất, chỉ ghi nhận “đã tái gia công” trên màn hình là chưa đủ. Cần phải theo dõi được việc cách ly sản phẩm không phù hợp khỏi kho thành phẩm, ai cho phép xử lý nào, sửa chữa theo phiên bản quy trình nào, đã vượt qua kiểm tra nào để đủ điều kiện xuất hàng. Đặc biệt tại các nhà máy ở Thái Lan, khi quyết định giữa trụ sở, bộ phận chất lượng, sản xuất và kho không đồng nhất, nếu ranh giới hệ thống mơ hồ thì giấy tờ và trao đổi miệng tại hiện trường vẫn tồn tại. Bài viết này cụ thể hóa chuyển trạng thái và liên kết dữ liệu, giúp bạn lựa chọn, định nghĩa yêu cầu, lập dự toán và kiểm thử nghiệm thu.
Quản lý rework không chỉ là “ghi nhận sản phẩm lỗi”, mà là kiểm soát quyết định xuất hàng
Rework là biện pháp thực hiện thêm công đoạn cho sản phẩm hoặc bán thành phẩm không phù hợp, nhằm khôi phục sự phù hợp với các yêu cầu đã định. Cần phân biệt với concession (đặc cách sử dụng/xuất hàng dù không đạt yêu cầu), sửa chữa có thay đổi thông số kỹ thuật, và loại bỏ (scrap). Tên gọi thực tế có thể khác nhau tùy hợp đồng khách hàng hoặc tiêu chuẩn ngành, vì vậy trong định nghĩa yêu cầu nên làm rõ sản phẩm sau xử lý sẽ phù hợp tiêu chuẩn nào, cần ai phê duyệt.
Nếu chỉ đăng ký sản phẩm không phù hợp thì hệ thống quản lý chất lượng (QMS) có thể đáp ứng, nhưng không đảm bảo xử lý xuyên suốt việc di chuyển hiện vật, tái đưa vào công đoạn, ghi nhận linh kiện và nhân công, tái kiểm tra, phục hồi trạng thái tồn kho. Ngược lại, nếu chỉ ghi nhận thực tế rework trên MES thì có thể thiếu phê duyệt xử lý từ bộ phận chất lượng hoặc khách hàng. Trọng tâm triển khai không phải là “thêm hệ thống mới”, mà là xác định hệ thống nào (QMS, MES, ERP, WMS) giữ bản gốc và hệ thống nào nhận thông báo khi trạng thái thay đổi.
Tài liệu hướng dẫn quản lý chất lượng của ISO liệt kê các ghi nhận về tính chất không phù hợp, biện pháp xử lý, concession, người quyết định xử lý. Đây không phải là quy định bắt buộc phải triển khai phần mềm cụ thể, nhưng là cơ sở để thiết kế lịch sử phê duyệt có thể giải trình sau này. Tài liệu truy xuất nguồn gốc của GS1 cũng nêu rõ, nếu bán thành phẩm đã tái gia công nằm trong phạm vi truy xuất, cần ghi nhận mối liên hệ giữa lô sản xuất hoặc serial với đầu vào/đầu ra. Việc đánh giá phù hợp tiêu chuẩn sẽ thực hiện riêng biệt dựa trên yêu cầu khách hàng và phạm vi kiểm toán.
Quyết định đầu tiên: “Đối tượng” và “đơn vị cách ly”
Nếu chỉ áp dụng cho thành phẩm, các lỗi phát hiện trong quá trình sản xuất sẽ còn lại trên sổ giấy ngoài công đoạn. Lỗi nhập nguyên liệu, lỗi kích thước trong công đoạn, không đạt kiểm tra chức năng sau lắp ráp, không đạt kiểm tra trước xuất hàng – dù đều là “không phù hợp”, nhưng bộ phận sở hữu và biện pháp xử lý được phép lại khác nhau. Hãy xác định mức độ nhận diện hiện vật (mã hàng, số lô, serial, thùng, pallet) dựa trên điểm phát hiện và ảnh hưởng đến công đoạn sau.
Ví dụ, nếu chỉ 7/100 sản phẩm cùng lô cần tái gia công, nếu xử lý cả lô cùng trạng thái thì hoặc phải giữ lại cả 93 sản phẩm đạt, hoặc có nguy cơ xuất nhầm 7 sản phẩm lỗi. Đây chỉ là ví dụ minh họa, không phải giá trị khuyến nghị. Nếu xử lý lô phân đoạn, cần liên kết lô mẹ, lô con, ID cá thể, số lượng, vị trí lưu kho, và đảm bảo tổng số trước/sau phân chia khớp nhau. Dù sau rework vẫn dùng cùng mã hàng, cần lưu lại mối quan hệ giữa hiện vật gốc và hiện vật sau xử lý trong lịch sử.
Với sản phẩm lớn không thể cách ly vật lý tại hiện trường, chỉ cách ly trên hệ thống là chưa đủ. Kết hợp các biện pháp như thẻ tag, phân vùng sàn, kệ, niêm phong thùng, cấm đưa vào thiết bị, để người thao tác xác nhận trạng thái qua hiện vật. Ngược lại, chỉ dùng thẻ vật lý thì không thể ngăn chặn xuất kho trên ERP hoặc WMS. Điều kiện hoàn thành cách ly không chỉ là “gắn thẻ”, mà là khi hiển thị hiện vật, vị trí lưu kho, trạng thái tồn kho, cấm xuất hàng đã đồng bộ.

Thiết kế chuyển trạng thái từ phát hiện không phù hợp đến phục hồi tồn kho
Các trạng thái tối thiểu có thể chia: ① Phát hiện, ② Cách ly, ③ Đang xét xử lý, ④ Phê duyệt rework, ⑤ Đang rework, ⑥ Chờ tái kiểm tra, ⑦ Đạt tái kiểm tra, ⑧ Có thể xuất hàng. Các nhánh rẽ gồm: không đạt, loại bỏ, concession, trả lại nhà cung cấp, chờ phê duyệt khách hàng. Không bắt buộc mọi công ty dùng cùng tên gọi, nhưng nếu không xác định rõ “ai, dựa trên dữ liệu nào, được phép chuyển sang trạng thái nào” thì chỉ là trường trạng thái đơn thuần.
Khi phát hiện không phù hợp, cần ghi nhận thời điểm phát hiện, thiết bị/công đoạn, hạng mục kiểm tra, kết quả đo, phiên bản tiêu chuẩn hoặc tiêu chí đánh giá, số lượng phát hiện, phạm vi nghi vấn, người phát hiện. Nếu giá trị đo nhập tay, cần lưu người nhập và lịch sử chỉnh sửa; nếu lấy từ thiết bị đo, cần gắn ID thiết bị và thời gian. Chỉ chọn một mã lỗi có thể không đủ để xác định hạng mục tái kiểm tra sau này. Cho phép mô tả tự do nhưng tách riêng các trường cấu trúc cần cho phân tích.
Khi chuyển sang cách ly, đối chiếu ID hiện vật và ID tồn kho, xác nhận số lượng đã loại khỏi tồn kho khả dụng. Nếu thời điểm cập nhật trên ERP, WMS, MES khác nhau, cần xác định hệ thống nào là cổng cuối cùng cấm xuất hàng. Nếu mất kết nối, không hiển thị là “đã cách ly” mà để lại trong hàng đợi ngoại lệ. Để tránh giảm số lượng hai lần do gửi trùng, cần có ID sự kiện và xử lý idempotent.
Ở bước xét xử lý, xác định vai trò của chất lượng, kỹ thuật sản xuất, sản xuất, và khi cần thiết là khách hàng. Không được phê duyệt cùng nút cho rework tiêu chuẩn và xử lý ngoại lệ không có quy trình. Với sản phẩm như linh kiện ô tô có yêu cầu riêng của khách hàng, có thể cần phê duyệt trước cho rework ngoài kế hoạch. Ví dụ, yêu cầu khách hàng của Stellantis công khai rằng rework đã lên kế hoạch phải được tích hợp vào luồng công đoạn, FMEA, kế hoạch kiểm soát, còn rework ngoài kế hoạch phải xin phê duyệt trước. Tuy nhiên, không nên áp dụng yêu cầu này cho sản phẩm hãng khác mà không kiểm tra hợp đồng áp dụng.
Sau khi phê duyệt rework, lệnh công việc phát sinh từ lệnh sản xuất gốc. Xác định có trả về công đoạn gốc, chuyển sang cell chuyên dụng, giới hạn số lần tái đưa vào, ghi nhận bổ sung/thay thế linh kiện, loại bỏ, nhân công, thiết bị, người thao tác ở đâu. Kiểm tra sau rework không nhất thiết chỉ lặp lại kiểm tra gốc, mà cần đánh giá lại các đặc tính bị ảnh hưởng, bổ sung kiểm tra hoặc thử nghiệm chức năng nếu cần.
Phục hồi trạng thái “có thể xuất hàng” chỉ thực hiện sau khi kết quả tái kiểm tra đã đầy đủ và người có thẩm quyền phê duyệt. Nếu WMS chưa gỡ cách ly, ERP chưa đổi trạng thái tồn kho, MES chưa cập nhật trạng thái hiện vật, QMS chưa hoàn tất xử lý, thì mỗi màn hình có thể cho kết quả khác nhau. Kiểm thử nghiệm thu cần xác nhận thứ tự xử lý giữa các hệ thống và quy trình hiệu chỉnh khi có lỗi.
Không nhầm lẫn giữa rework, repair, concession và scrap
Mục tiêu của rework là khôi phục sản phẩm về đúng yêu cầu ban đầu. Repair là đưa về trạng thái sử dụng được nhưng có thể không đáp ứng toàn bộ yêu cầu gốc; concession là cho phép sử dụng/xuất hàng dù biết không phù hợp, do người có thẩm quyền quyết định; scrap là cấm tái sử dụng, quản lý đến công đoạn loại bỏ hiện vật. Không chỉ đưa các lựa chọn này lên màn hình, mà cần xác định riêng người phê duyệt, tái kiểm tra, thông báo khách hàng, nhãn, trạng thái tồn kho, liên kết kế toán cho từng biện pháp.
Cùng một sản phẩm, nếu gia công thêm kích thước để đạt chuẩn thì là rework; nếu dùng thông số thay thế và được khách hàng đồng ý thì gần với concession. Các ví dụ này chỉ nhằm giúp phân loại, không thay thế phán quyết pháp lý hoặc tiêu chuẩn. Hãy tập hợp các trường hợp khó phân xử tại nhà máy, cùng người chịu trách nhiệm chất lượng sắp xếp thứ tự ưu tiên giữa bản vẽ khách hàng, hợp đồng, thỏa thuận chất lượng, quy trình nội bộ.
Thay đổi biện pháp xử lý cũng cần lưu vào lịch sử. Nếu ban đầu dự kiến rework nhưng sau kiểm tra lại không đạt và chuyển sang scrap, việc ghi đè phê duyệt cũ sẽ làm mất lịch sử. Cần lưu lý do vô hiệu hóa quyết định cũ, người phê duyệt quyết định mới, di chuyển số lượng hiện vật, nhân công bổ sung theo trình tự thời gian. Nếu chỉ lưu “trạng thái cuối cùng”, việc phân tích tỷ lệ lỗi hoặc chi phí rework sẽ bị sai lệch.
Phân công vai trò giữa QMS, MES, ERP, WMS
QMS thường quản lý báo cáo không phù hợp, phân tích nguyên nhân, quyết định xử lý, phê duyệt, biện pháp khắc phục; MES thường quản lý luồng công đoạn, thực tế công việc, tái đưa vào, tái kiểm tra; ERP quản lý lệnh sản xuất, mã hàng, giá thành, kế toán, đánh giá tồn kho; WMS quản lý vị trí, di chuyển hiện vật, cấm picking. Tuy nhiên, ranh giới này khác nhau tùy sản phẩm, không nên chỉ dựa vào tên hệ thống để phân công trách nhiệm. Hãy lập “ma trận trách nhiệm” chỉ định bản gốc cho từng trường dữ liệu.
Các sự kiện tối thiểu khuyến nghị gồm: NONCONFORMANCE_OPENED, HOLD_APPLIED, DISPOSITION_APPROVED, REWORK_STARTED, REWORK_COMPLETED, REINSPECTION_PASSED, RELEASE_APPROVED. Tên gọi chỉ là ví dụ thiết kế, quan trọng là mỗi sự kiện có ID, hiện vật liên quan, số lượng, thời điểm, người thao tác, phiên bản phê duyệt, nguồn phát, liên kết sự kiện trước. Đảm bảo các hệ thống nhận cùng sự kiện không cập nhật trùng lặp.
Xử lý lỗi liên kết là trọng tâm quyết định triển khai. Ví dụ, ngay sau khi bộ phận chất lượng xác nhận cách ly mà ERP mất kết nối, màn hình chất lượng hiển thị đã cách ly nhưng ERP vẫn cho phép xuất hàng. Trong RFP, không chỉ hỏi “có thể gửi lại không”, mà còn “cổng xuất hàng dựa vào dữ liệu nào để chặn”, “ai sẽ được thông báo khi đồng bộ lỗi, trong bao lâu”, “sau khi phục hồi sẽ đối chiếu số lượng thế nào”. Thời gian thông báo tùy vận hành và rủi ro của doanh nghiệp, cần đo thực tế để quyết định.
Bài viết Cách loại bỏ nhập liệu trùng lặp trong sản xuất đã phân tích bản gốc và đồng bộ giữa MES, ERP, WMS. Ngoài ra, Triển khai hệ thống quản lý gia công ngoài đề cập thiết kế đối chiếu vật tư cấp phát và số lượng nhận về khi gia công ngoài. Nếu công đoạn rework giao cho đối tác ngoài, hãy liên kết quản lý cách ly, phê duyệt xử lý nội bộ với giao nhận bên ngoài theo hai góc nhìn này.

Triển khai truy xuất nguồn gốc và phân chia lô
Ngay cả khi rework chỉ là sửa chữa đơn giản không thêm nguyên liệu, vẫn cần truy vết được ai, khi nào, theo điều kiện nào, tiêu chuẩn kiểm tra nào đã xử lý. Nếu có thay thế linh kiện, trộn lẫn, đóng gói lại, dán nhãn lại, phân chia lô, thì càng cần liên kết rõ ID đầu vào và đầu ra. TransformationEvent trong GS1 EPCIS là khái niệm tiêu chuẩn thể hiện mối quan hệ này. Không bắt buộc phải triển khai EPCIS cho rework, nhưng đây là tham khảo hữu ích cho thiết kế liên kết đầu vào/đầu ra thành các bản ghi riêng biệt.
Cân đối số lượng có thể giải thích như: nhập kho 100, cách ly 7, hoàn thành rework 6, loại bỏ 1, phục hồi về thành phẩm 6. Tuy nhiên, chỉ nhìn số “cách ly 7” và “phục hồi 6” thì không biết 1 sản phẩm nào bị loại bỏ, 6 sản phẩm nào đã qua quy trình nào. Với sản phẩm cần nhận diện cá thể, truy vết theo serial; với sản phẩm quản lý theo lô, truy vết theo lô phân đoạn; nếu rework nhiều lần trên cùng công đoạn, lưu cả số lần và nguyên nhân. Các số liệu chỉ là ví dụ minh họa, không phải tiêu chuẩn hay thực tế.
Khi điều tra lỗi sau xuất hàng, cần cả hai chiều: truy ngược chỉ các sản phẩm đã rework, và truy xuôi từ lô cụ thể đến nơi đã xuất. Nếu chỉ nhìn tỷ lệ lỗi trên luồng chuẩn, sản phẩm rework sẽ bị hòa lẫn với sản phẩm thường. Hãy kiểm tra có thể tái hiện liên kết vật tư bổ sung, kết quả tái kiểm tra, phê duyệt khách hàng, lô xuất hàng trên dữ liệu thử nghiệm hay không.
Cách ước tính chi phí và hiệu quả triển khai
Chi phí hệ thống quản lý rework không chỉ phụ thuộc số lượng màn hình. Trước tiên, xác định mức độ tận dụng được của QMS, MES, ERP, WMS hiện có, rồi phân tách chức năng bổ sung. Dự toán cần bao gồm: mức độ nhận diện hiện vật, thiết bị đầu cuối/máy quét/nhãn, đa điểm và đa ngôn ngữ, luồng phê duyệt, nhánh công đoạn, chuyển đổi dữ liệu, giao diện liên kết, xử lý offline, nhật ký kiểm toán, bảo trì và đào tạo. Giá cụ thể phụ thuộc môi trường kết nối và điều kiện hợp đồng, không đưa ra mức giá chung không có cơ sở.
Hiệu quả đầu tư không thể chỉ dựa vào tuyên bố “giảm tỷ lệ lỗi”. So sánh thời gian lưu lại đến khi gỡ cách ly, phòng ngừa xuất nhầm, nhân công rework, thời gian chờ tái kiểm tra, tái phát lỗi cùng loại, tỷ lệ loại bỏ, tồn kho bán thành phẩm, thời gian điều tra trước/sau triển khai. Việc trực quan hóa dữ liệu chất lượng giúp phân tích nguyên nhân nhanh hơn, nhưng nếu không thực hiện cải tiến thì lỗi không giảm. Phân biệt rõ hiệu quả của hệ thống và hiệu quả cải tiến công đoạn khi báo cáo.
Ví dụ, nhà máy có 200 phiếu không phù hợp mỗi tháng, trong đó 40 chuyển sang rework, thì trước khi áp dụng quản lý serial cá thể tốn kém cho toàn bộ, hãy đo thời gian từ phát hiện đến khi được phép xuất hàng, số lần quay lại, chênh lệch tồn kho trên các trường hợp rework. Các con số chỉ là ví dụ minh họa cách tính toán. Khi quyết định đầu tư, hãy dùng số liệu phát sinh, đơn giá nhân công, yêu cầu khách hàng, rủi ro kiểm toán, chi phí cải tiến hệ thống thực tế của doanh nghiệp.
Các chức năng và trường dữ liệu nên ghi trong RFP
Trong RFP, tránh mô tả chung chung như “quản lý được sản phẩm không phù hợp”, mà hãy đưa các tình huống bất thường thực tế thành kịch bản nghiệp vụ. Tối thiểu nên bao gồm: lô phân đoạn không đạt kiểm tra công đoạn, cách ly khi nhập nguyên liệu, truy vết sản phẩm đã chuyển sang công đoạn sau, yêu cầu phê duyệt cho rework ngoài kế hoạch, tái kiểm tra lại không đạt, đồng bộ sau khi mất kết nối, số lượng nhận về từ gia công ngoài thiếu hụt. Không cần yêu cầu tất cả trường hợp không có tại doanh nghiệp mình.
Bảng chức năng nên liệt kê: ① Nhận diện hiện vật/lô/số lượng, ② Cách ly và cấm xuất hàng, ③ Loại biện pháp xử lý, ④ Quyền phê duyệt, ⑤ Phiên bản quy trình thao tác, ⑥ Vật tư và nhân công sử dụng, ⑦ Kế hoạch tái kiểm tra, ⑧ Quyền phục hồi xuất hàng, ⑨ Đồng bộ tồn kho với ERP/WMS, ⑩ Tìm kiếm và nhật ký kiểm toán. Với mỗi mục, yêu cầu phân loại “chức năng chuẩn”, “cấu hình được”, “phát triển bổ sung”, “không hỗ trợ”, và minh chứng qua demo. Chỉ đánh dấu tròn trong tài liệu không đủ để đánh giá khả năng triển khai.
Cũng cần ghi rõ chủ sở hữu dữ liệu trong RFP. Ví dụ: số phiếu không phù hợp thuộc QMS, thời gian bắt đầu/kết thúc công việc thuộc MES, số lượng khả dụng cho xuất kho thuộc ERP hoặc WMS, số phê duyệt khách hàng thuộc QMS. Hỏi rõ không chỉ API hay file, mà cả bảng đối chiếu ID, thứ tự gửi lại, loại bỏ trùng lặp, quy trình hiệu chỉnh khi lỗi, thời gian lưu trữ cho kiểm toán.
So sánh nhà cung cấp không chỉ dựa vào giá, mà kiểm tra thực tế việc phê duyệt xử lý và kiểm soát hiện vật có vận hành đồng bộ không qua dữ liệu thử nghiệm. Nếu sản phẩm hiện có thiếu chức năng, đôi khi chỉ cần bổ sung workflow hoặc liên kết sự kiện thay vì chỉnh sửa sâu lõi hệ thống. Tuy nhiên, càng nhiều ranh giới thì trách nhiệm khi có sự cố càng phức tạp, nên cần thống nhất rõ giữa đơn vị triển khai, vận hành, chịu trách nhiệm chất lượng trước khi ký hợp đồng.
Tiêu chí nghiệm thu cần xác nhận qua PoC, FAT, SAT
Trong PoC, thay vì chọn lỗi phát sinh nhiều nhất, hãy chọn các trường hợp đại diện vượt qua ranh giới trạng thái và hệ thống để dễ phát hiện thiếu sót. Thực hiện chuỗi: cách ly lô phân đoạn, phê duyệt chất lượng, phát hành lệnh rework, ghi nhận vật tư và nhân công, tái kiểm tra chỉ một phần đạt, chỉ sản phẩm đạt mới phục hồi về tồn kho xuất hàng. Kiểm tra cả trường hợp sản phẩm không đạt tái kiểm tra lại quay về cách ly, lịch sử không bị mất.
FAT kiểm tra quyền hạn vai trò, màn hình và biểu mẫu, API, điều kiện bảo toàn số lượng, trùng lặp sự kiện, mất kết nối, thời gian và nhật ký kiểm toán. Ví dụ, nếu người thao tác cố gắng bắt đầu rework trước khi chất lượng phê duyệt, phải bị chặn. Nếu người khác mở quy trình phiên bản cũ, phải không thực hiện được hoặc có hướng dẫn rõ chuyển sang phiên bản mới. Số lượng và thời gian kiểm thử tùy điều kiện nhà máy.
SAT kiểm tra thực tế trên thiết bị đầu cuối, mã vạch, nhãn, mạng không dây, vận hành thiết bị, vị trí hiện vật, giao diện đa ngôn ngữ (Thái, Nhật…). Chủ động tạo tình huống lệch: màn hình báo cách ly nhưng hiện vật không có tag, hoặc hiện vật đã cách ly nhưng ERP vẫn cho xuất kho, để kiểm tra ai phát hiện và quy trình phục hồi. Đừng kích hoạt cổng xuất hàng thực tế chỉ dựa vào dữ liệu mẫu thành công.
Việc nghiệm thu phải bằng tài liệu, bao gồm ngoại lệ được phép, thời gian phục hồi tại hiện trường, quy trình quay lại thao tác thủ công, người chịu trách nhiệm. “Màn hình chạy được” không đồng nghĩa với nghiệm thu. Điều kiện hoàn thành là tái hiện đầy đủ kịch bản nghiệp vụ từ đầu đến cuối, dữ liệu hiện vật, số lượng, phê duyệt, kiểm tra, tồn kho, xuất hàng khớp nhau.

Các lỗi thường gặp và cách phòng tránh
Thứ nhất, nhầm lẫn giữa hoàn thành phiếu chất lượng và phục hồi hiện vật là một. Dù đã quyết định xử lý, nếu chưa hoàn thành rework và tái kiểm tra thì vẫn phải cấm xuất hàng. Phân tách trạng thái và quyền thay đổi. Thứ hai, ID hiện vật bị thay đổi giữa chừng, mất liên kết giữa sản phẩm không phù hợp và sản phẩm sau rework. Kiểm tra quan hệ cha-con khi in lại nhãn, phân chia, đóng gói lại.
Thứ ba, chỉ xây dựng luồng rework tiêu chuẩn, còn phê duyệt xử lý ngoài kế hoạch vẫn làm trên giấy. Dù tần suất thấp nhưng rủi ro cao, cần đưa vào thiết kế. Thứ tư, chỉ ghi nhận “đạt/không đạt” khi tái kiểm tra, không lưu hạng mục nào đã kiểm tra lại theo tiêu chuẩn nào. Đảm bảo truy vết lý do kiểm tra bổ sung và giá trị đo. Thứ năm, coi đồng bộ giữa các hệ thống là thành công dù thực tế lỗi. Đặc biệt với cách ly và phục hồi, cần hiển thị lỗi rõ ràng, thiết kế cổng xuất hàng an toàn.
Trình tự triển khai và tổ chức vận hành tại nhà máy Thái Lan
Khi trụ sở quyết định quy trình chất lượng, nhà máy Thái Lan vận hành hiện vật, khác biệt ngôn ngữ không chỉ là vấn đề hiển thị. Nếu các thuật ngữ “hold”, “rework”, “repair”, “concession”, “release” được các bộ phận hiểu khác nhau, cùng một trường hợp sẽ bị báo cáo thành các trạng thái khác nhau. Hãy lập bảng thuật ngữ Nhật-Anh-Thái, thống nhất điều kiện vào, thao tác thực hiện, điều kiện ra cho từng trạng thái trên một bảng duy nhất. Giao diện hiện trường có thể dùng từ ngắn, nhưng phần giải thích cho người phê duyệt phải đầy đủ.
Giai đoạn đầu, không nên chọn công đoạn có nhiều trường hợp phát sinh nhất, mà chọn công đoạn ranh giới giữa chất lượng và kho rõ ràng. Ví dụ, nếu không đạt kiểm tra sau lắp ráp, có thể di chuyển sản phẩm sang kệ cách ly, quyết định xử lý, chuyển sang cell rework, tái kiểm tra, phục hồi về kệ thành phẩm – hoàn thành một vòng khép kín. Nếu mở rộng ngay từ đầu cho toàn bộ điểm, mã hàng, biện pháp, sẽ không kịp định nghĩa ngoại lệ, hiện trường dễ quay lại vận hành giấy. Các trường hợp chưa làm trong PoC cần liệt kê điều kiện chuyển sang giai đoạn tiếp theo.
Phân vai gồm: người phát hiện, người cách ly, người xét xử lý, người phê duyệt rework, người thao tác, người kiểm tra, người phê duyệt phục hồi, người hiệu chỉnh tồn kho. Dù một người kiêm nhiều vai, vẫn phải lưu log rõ thực hiện thao tác nào với quyền nào. Nếu hợp đồng hoặc quy định nội bộ yêu cầu độc lập đảm bảo chất lượng, cấu hình quyền để người hoàn thành thao tác không tự phê duyệt phục hồi cuối cùng. Nếu ca đêm/ngày nghỉ không có người phê duyệt, cần chỉ định người thay thế và thời hạn phê duyệt trước, tránh để sản phẩm tự động chuyển công đoạn khi chưa phê duyệt.
Khi chuyển đổi từ giấy, việc xử lý hiện vật đang cách ly trước ngày triển khai rất quan trọng. Nếu tự động coi toàn bộ tồn kho là “thành phẩm” vào ngày chuyển đổi, sản phẩm không phù hợp trên sổ cũ sẽ bị phục hồi nhầm. Trước khi chuyển đổi, kiểm kê thực tế, đối chiếu phiếu không phù hợp chưa hoàn thành, lô cách ly, chờ phê duyệt khách hàng, chờ loại bỏ. Dữ liệu chuyển đổi cần ghi số phiếu gốc và người chuyển đổi, để phân biệt với trường hợp phát sinh sau khi chạy hệ thống mới.
Đào tạo không chỉ hướng dẫn thao tác, mà còn giải thích tại sao không được gỡ cách ly, tại sao “hoàn thành” sau rework và “có thể xuất hàng” là khác nhau, bằng hiện vật thực tế. Đào tạo giả lập thao tác sai cũng hữu ích: khi quét mã quy trình cũ, quét nhãn lô khác, mất kết nối, người thao tác sẽ xem màn hình và hiện vật nào, báo cho ai. Sau khi vận hành ổn định, kiểm tra số lượng trường hợp tồn đọng trong hàng đợi ngoại lệ và số trường hợp còn vận hành song song giấy.
Dashboard không chỉ tập trung vào “tỷ lệ lỗi”
Tỷ lệ phát sinh không phù hợp rất quan trọng, nhưng nút thắt trong quản lý rework có thể nằm ở chờ phê duyệt hoặc chờ tái kiểm tra. Hãy tổng hợp thời gian lưu lại theo từng trạng thái: từ phát hiện đến cách ly, từ cách ly đến phê duyệt xử lý, từ phê duyệt đến bắt đầu thao tác, từ hoàn thành đến tái kiểm tra, từ tái kiểm tra đến phục hồi tồn kho. Chỉ nhìn giá trị trung bình sẽ che giấu các trường hợp tồn đọng lâu, nên cần hiển thị cả phân bố số lượng và trường hợp lâu nhất. Không quy kết mọi tồn đọng là do hiện trường, mà phân biệt rõ chờ phê duyệt khách hàng, chờ vật tư.
Cố định mẫu số khi tính tỷ lệ rework: số đầu vào, số hoàn thành, số kiểm tra – chọn mẫu số nào sẽ cho kết quả khác nhau. Phân biệt rõ rework lần hai trên cùng sản phẩm tính là hai trường hợp hay một cá thể. Nếu trộn lẫn chỉ số cho lãnh đạo và chỉ số cải tiến công đoạn dưới cùng tên gọi, sẽ so sánh sai giữa các điểm. Ghi rõ định nghĩa trường dữ liệu và kỳ tổng hợp trên dashboard, khi thay đổi phải lưu ảnh hưởng đến số liệu cũ.
Phân tích chi phí không chỉ gồm nhân công rework, mà cả vật tư bổ sung, tái kiểm tra, chiếm dụng thiết bị, chi phí gia công ngoài, loại bỏ, lưu kho bán thành phẩm. Tuy nhiên, ngay sau khi tăng số trường hợp có thể tổng hợp, chi phí rework có thể tăng do các khoản trước đây chưa thấy. Khi đánh giá hiệu quả cải tiến, cần tách riêng thay đổi phương pháp đo và cải tiến thực tế. Để phân tích nguyên nhân, tách riêng trường “phát hiện không phù hợp ở công đoạn nào” và “có thể phát sinh ở công đoạn nào”.
Bộ phận chất lượng không chỉ cần danh sách mã lỗi nhiều nhất, mà còn cần tỷ lệ không đạt sau rework, số lần xử lý lại trên cùng lô, liên quan đến cùng thiết bị/khuôn/lô vật tư, thời gian chờ phê duyệt khách hàng. Kết hợp các chỉ số này giúp xác định thiếu sót quy trình thao tác hay điều kiện công đoạn gốc không ổn định. Dù phát hiện tương quan, không nên vội kết luận quan hệ nhân quả mà phải kiểm tra thực tế và điều kiện đo lường.
Tài liệu cần bàn giao khi triển khai
Nếu chỉ yêu cầu danh sách màn hình từ nhà cung cấp, người tiếp quản vận hành sẽ không hiểu trạng thái và trách nhiệm. Tối thiểu cần bàn giao: sơ đồ chuyển trạng thái, bảng quyền hạn, quy tắc ID hiện vật, bảng bản gốc trường dữ liệu, danh sách sự kiện giữa hệ thống, quy trình phục hồi khi liên kết lỗi, quản lý phiên bản kế hoạch kiểm tra, chính sách lưu nhật ký kiểm toán, phản hồi RFP, kết quả FAT/SAT. Thời gian lưu trữ khác nhau tùy sản phẩm, luật và hợp đồng, nên bộ phận chất lượng/pháp chế quyết định, hệ thống cho phép cấu hình và trích xuất.
Quy trình vận hành hiện trường cần kèm lưu đồ riêng cho trường hợp không phù hợp thông thường và xử lý ngoài kế hoạch. Nếu không dùng được màn hình, quy định rõ ghi nhận tạm trên giấy: đánh số phiếu, hiển thị cách ly, chặn xuất hàng, nhập lại sau khi phục hồi, kiểm tra trùng lặp. Nếu không có quy trình quay lại giấy mà dừng hệ thống, ca đêm sẽ không xác định được vị trí và khả năng xuất hàng của hiện vật. Ngược lại, nếu song song giấy vô thời hạn, sẽ có hai bản gốc, cần quy định rõ bản nào là cuối cùng sau khi phục hồi.
Quản lý thay đổi sau khi vận hành cũng cần thiết kế. Nếu thay đổi yêu cầu khách hàng hoặc tiêu chuẩn kiểm tra, cần quyết định áp dụng phiên bản cũ hay mới cho các trường hợp đang cách ly. Không ghi đè quy trình, mà lưu thời điểm hiệu lực, mã hàng, khách hàng, người phê duyệt, điều kiện chuyển đổi cho các trường hợp đang xử lý. Sau khi thay đổi, kiểm thử lại kịch bản đại diện, xác nhận phê duyệt rework và cổng xuất hàng hoạt động đúng.
Hợp đồng bảo trì sau nghiệm thu nên bao gồm: cách đối chiếu hiện vật và tồn kho khi có sự cố, kiểm thử hồi quy khi thay đổi giao diện, cập nhật quy cách nhãn, kiểm tra định kỳ quyền hạn, hỗ trợ trích xuất log. Nếu chỉ đến sát ngày kiểm toán chất lượng mới ghép lịch sử thủ công, hiệu quả triển khai sẽ không bền vững. Họp vận hành hàng tháng cần kiểm tra lỗi liên kết chưa xử lý, sản phẩm cách ly lâu, số lần phê duyệt thay thế, thử sử dụng quy trình cũ, để cải tiến cả quy trình và cấu hình.
Câu hỏi thường gặp
Chi phí triển khai hệ thống quản lý rework phụ thuộc vào những yếu tố nào?
Phụ thuộc vào chức năng QMS/MES/ERP/WMS hiện có, số lượng liên kết, mức độ nhận diện hiện vật, phê duyệt và yêu cầu khách hàng, thiết bị đầu cuối/nhãn, đa ngôn ngữ, hỗ trợ offline. Hãy chọn một luồng hiện tại, tách riêng chức năng bổ sung và liên kết cần thiết từ cách ly đến phục hồi để lập dự toán. Chỉ nhìn giá không thể so sánh phạm vi chuyển đổi dữ liệu và xử lý ngoại lệ.
Có thể bắt đầu từ sổ Excel ghi nhận không phù hợp không?
Có thể. Tuy nhiên, không nên chỉ chuyển sổ sang màn hình, mà cần định nghĩa rõ ID hiện vật, số lượng, quyền xử lý, tái kiểm tra, trạng thái tồn kho, cấm xuất hàng. Nên giới hạn ban đầu cho một công đoạn hoặc nhóm mã hàng, xác định thời gian song song giấy/Excel và điều kiện kết thúc để dễ chuyển đổi.
Sau rework có nên đổi số lô không?
Không có câu trả lời chung. Quyết định dựa trên tiêu chuẩn sản phẩm, yêu cầu khách hàng, nhận diện cá thể, nội dung rework, số lượng phân chia, phạm vi truy vết. Dù đổi hay không đổi số lô, quan trọng là truy vết được sản phẩm gốc, biện pháp xử lý, vật tư sử dụng, tái kiểm tra, nơi xuất hàng. Hãy quyết định cùng người chịu trách nhiệm chất lượng và đối chiếu hợp đồng khách hàng.
Nên cải tiến QMS hay MES trước?
Nếu thiếu lịch sử phê duyệt không phù hợp, ưu tiên QMS; nếu không truy vết được tái đưa vào công đoạn và thực tế thao tác, ưu tiên MES; nếu không chặn được xuất hàng, ưu tiên ERP/WMS. Hãy theo dõi một trường hợp không phù hợp thực tế, bắt đầu từ điểm kiểm soát quan trọng nhất. Không nên cố định thứ tự ưu tiên theo hệ thống từ đầu để tránh nhập liệu trùng lặp.
Tổng kết
Thành công của triển khai hệ thống quản lý rework không nằm ở việc số hóa phiếu rework, mà ở khả năng kết nối liền mạch giữa cách ly hiện vật, phê duyệt xử lý, phiên bản quy trình thao tác, tái kiểm tra, phục hồi tồn kho, cổng xuất hàng. Hãy theo dõi một trường hợp không phù hợp thực tế từ phát hiện đến khi có thể xuất hàng, xác định các điểm còn phải dùng giấy hoặc trao đổi miệng. Chuyển kết quả này thành sơ đồ trạng thái, ma trận trách nhiệm, RFP, tiêu chí nghiệm thu FAT/SAT sẽ giúp so sánh sản phẩm cụ thể hơn.
Ngay cả khi đang sắp xếp ranh giới QMS, MES, ERP, WMS và luồng phê duyệt rework tại nhà máy Thái Lan, bạn có thể liên hệ TOMAS TECH để trao đổi. Chúng tôi sẽ cùng bạn xem xét trên cơ sở phiếu không phù hợp và luồng hiện vật hiện tại, xác định phạm vi tối thiểu và kịch bản kiểm thử phù hợp.
Tài liệu tham khảo
- ISO, Hướng dẫn về tài liệu cho ISO 9001:2015
- IATF Global Oversight, Yêu cầu riêng của khách hàng Stellantis cho IATF 16949
- Tiêu chuẩn Truy xuất nguồn gốc toàn cầu GS1
- Danh sách kiểm tra truy xuất nguồn gốc toàn cầu GS1
- Tiêu chuẩn GS1 EPCIS 2.0.1
- NIST, Giao diện nền tảng đối tượng lập kế hoạch và thực thi sản xuất
- NIST, Nguyên tắc truy xuất nguồn gốc chuỗi cung ứng: Khung meta cho sản xuất