Nâng cao năng suất nhà máy bằng AI: Triển khai dự báo trễ giao hàng và nghiệm thu

Ngay cả khi đã triển khai AI dự đoán trễ giao hàng, chỉ hiển thị “Xác suất trễ 70%” trên màn hình cũng không đủ để đảm bảo giao hàng đúng hạn. Để thực sự nâng cao năng suất nhà máy bằng AI, cần thiết kế rõ ràng: thông tin nào được dùng để dự đoán, ai có quyền xử lý từng đơn hàng, và ai sẽ liên hệ với khách hàng vào thời điểm nào. Bài viết này cụ thể hóa RFP và kiểm thử nghiệm thu khi triển khai AI dự đoán trễ giao hàng cho các quản lý sản xuất, IT nhà máy, nhân viên kinh doanh và mua hàng tại các cơ sở sản xuất sử dụng ERP và MES, bao gồm cả Thái Lan. Các con số và ngưỡng dưới đây chỉ là giả định minh họa, không phải mức trung bình ngành hay tỷ lệ cải thiện đã được kiểm chứng.

“Nâng cao năng suất bằng AI” – Cụ thể hóa vào công việc quyết định giao hàng

Năng suất nhà máy không chỉ đo bằng tỷ lệ vận hành thiết bị. Nếu chỉ phát hiện nguy cơ trễ sớm mà không gắn kết thông tin đó với quyết định của người phụ trách, có thể chỉ làm tăng làm thêm giờ, vận chuyển khẩn cấp, hoặc tồn kho bán thành phẩm. Dự đoán chỉ hữu ích khi vẫn còn lựa chọn để đảm bảo giao hàng đúng hạn, và có thể hành động ở cấp từng đơn hàng. Ví dụ, trước khi kinh doanh liên hệ khách hàng, nhà máy có thể cân nhắc chuyển sang dây chuyền thay thế? Nếu thiếu vật tư, bộ phận mua hàng có thể tìm nguồn thay thế? Khoảng thời gian này cần được đưa vào tiêu chí nghiệm thu.

Nếu muốn tổng hợp các loại AI lập kế hoạch sản xuất và các điểm cần lưu ý khi triển khai, hãy tham khảo giải thích về AI lập kế hoạch sản xuất. Các biện pháp phổ biến về trực quan hóa tiến độ và phòng ngừa trễ giao hàng được trình bày trong bài viết về phòng ngừa trễ giao hàng. Bài viết này đi sâu hơn, tập trung vào các vấn đề thực thi và mua sắm: “cố định thời điểm đánh giá, kiểm chứng dự đoán, và theo dõi kết quả can thiệp” cho từng đơn đặt hàng/sản xuất.

Không chỉ nói chung chung “dự đoán giao hàng”

Ngày hứa với khách, ngày mong muốn trên ERP, ngày dự kiến hoàn thành tại nhà máy, ngày dự kiến xuất kho, ngày vận chuyển nhận hàng, ngày khách nhận hàng – tất cả là các mốc thời gian khác nhau. Nếu không xác định rõ mục tiêu dự đoán, AI có thể coi đơn hàng mà hiện trường cho là đúng hạn thành trễ, hoặc ngược lại. Trước tiên, bộ phận kinh doanh, logistics, quản lý sản xuất cần thống nhất nhãn “trễ giao hàng”. Ví dụ, có thể định nghĩa là các dòng đơn hàng không hoàn thành kiểm tra, đóng gói và xác nhận xuất hàng trước hạn đã thỏa thuận với khách. Tuy nhiên, nếu điểm giao hàng theo hợp đồng là kho khách, chỉ xuất xưởng từ nhà máy chưa đủ. Cần lưu lại sự khác biệt theo khách hàng, sản phẩm, điều kiện giao dịch trong tài liệu đặc tả.

Nếu một đơn hàng có nhiều dòng và cho phép giao từng phần, cũng cần định nghĩa rõ. Xác định tính theo toàn bộ đơn hàng hay từng dòng và ngày hứa sẽ làm thay đổi mẫu số. Cần quyết định cách xử lý các trường hợp hủy, tái thỏa thuận ngày giao, thay đổi thủ công bởi kinh doanh, hoặc đặc cách đột xuất. Nếu thay đổi nhãn đúng/sai sau này cho thuận tiện, chỉ làm đẹp số liệu mô hình mà không cải thiện quyết định ứng xử với khách.

Kết nối ERP, MES và sự kiện hiện trường về cùng một dòng đơn hàng

ISA-95 là khung tham chiếu cho trao đổi thông tin giữa hệ thống nghiệp vụ doanh nghiệp và vận hành sản xuất. ERP được mô tả ở cấp gần với hoạch định kinh doanh/logistics, MES gần với vận hành sản xuất. Tuy nhiên, ISA-95 không chỉ định mô hình AI hay sản phẩm cơ sở dữ liệu cụ thể. Trong trường hợp này, ISA-95 giúp hệ thống hóa mã định danh, ý nghĩa, trách nhiệm cập nhật khi kết nối thông tin hứa giao của ERP, tiến độ MES, và sự kiện thiết bị.

Sai sót đầu tiên dễ xảy ra khi tích hợp là nhầm lẫn các mã số tương tự là cùng ý nghĩa. Không nên mặc định số đơn hàng khách và số đơn nội bộ, lệnh sản xuất và lệnh tái sản xuất, lô mẹ và lô tách là một-một. Cần có bảng đối chiếu trung gian và lịch sử phiên bản, các dòng không liên kết được phải được đếm là thiếu, không âm thầm loại bỏ. Nếu hiển thị “rủi ro thấp” cho các mục không đối chiếu được, các trường hợp khó nhất sẽ biến mất khỏi danh sách.

Quản lý ba loại thời điểm

Tối thiểu cần phân biệt thời điểm phát sinh tại hiện trường, thời điểm đăng ký vào hệ thống, và thời điểm đánh giá của mô hình. Nếu ca đêm nhập liệu giấy vào sáng hôm sau, dù có lùi thời điểm phát sinh về ngày trước, AI vào tối hôm trước cũng không thể biết được thực tế đó. Đặc trưng dùng cho học và kiểm thử chỉ lấy thông tin hệ thống có thể truy cập đến thời điểm đánh giá. Nếu kết nối giữa Thái Lan và Nhật Bản, cần chuẩn hóa thời gian nội bộ (ví dụ UTC), và hiển thị múi giờ địa phương rõ ràng trên giao diện. Không suy đoán giờ từ cột chỉ có ngày.

Chỉ định rõ người chịu trách nhiệm dữ liệu cho từng mục tích hợp

“ERP và MES tích hợp” không đủ làm đặc tả RFP. Với từng mục, cần lập bảng: hệ thống gốc, người cập nhật, tần suất cập nhật, độ trễ cho phép, cách sửa đổi, hiển thị khi không đối chiếu được. Ví dụ, nếu chỉ kinh doanh được phép cập nhật ngày hứa trên ERP, AI không được tự động ghi đè ngày mong muốn trên MES. Nếu lý do ngừng thiết bị chưa xác định, không dùng mã lỗi tạm thời để học. Việc minh bạch hóa trách nhiệm nhập liệu và sửa chữa giúp phân biệt lỗi mô hình và lỗi vận hành dữ liệu.

Cố định thời điểm đánh giá và kiểm soát rò rỉ dữ liệu

Dự đoán trễ giao hàng rất dễ bị “rò rỉ dữ liệu” – sử dụng thông tin chỉ biết được sau này. Nếu dùng ngày xác nhận xuất hàng, kết quả kiểm tra khi hoàn thành, hoặc cờ vận chuyển khẩn sau khi biết trễ để học, mô hình sẽ có vẻ rất chính xác trên dữ liệu quá khứ. Nhưng người phụ trách hôm trước không thể biết các thông tin đó, nên không thể tái hiện khi vận hành. Cần kiểm tra rò rỉ dữ liệu này. Trong kiểm thử nghiệm thu, lưu lại với từng dòng dự đoán: thời điểm đánh giá, phiên bản dữ liệu sử dụng, thời điểm có thể lấy đặc trưng, phiên bản mô hình, để kiểm toán có thể tái hiện từng trường hợp.

Ví dụ, giả định vận hành đánh giá các đơn hàng hứa giao trong 7 ngày tới vào 08:00 mỗi ngày. Sử dụng phiên bản đơn hàng ERP lúc 08:00 và các sự kiện MES đến trước 08:00, các thực tế nhập lúc 09:30 cho ngày hôm trước sẽ không dùng cho đánh giá hôm đó. Nếu thực tế được sửa sau này, không tự động cập nhật lại dự đoán quá khứ thành “giá trị biết tại thời điểm đó”. Dùng bản sửa cho lần đánh giá tiếp theo, lưu bản cũ cho kiểm toán. Đây chỉ là ví dụ thiết kế, không có nghĩa 08:00 hay 7 ngày là chuẩn ngành.

Dữ liệu học chia theo chuỗi thời gian. Nếu trộn các công đoạn trước của cùng đơn hàng vào tập huấn luyện, công đoạn sau vào kiểm thử, có thể rò rỉ kết quả của cùng một vụ việc. Có dùng chia ngẫu nhiên đơn giản hay không tùy vào tính độc lập của đơn hàng, nhưng tối thiểu phải có kiểm thử giữ nguyên chuỗi thời gian tương lai. Bao gồm cả mùa cao điểm, sản phẩm mới, cải tạo thiết bị, thay đổi mẫu đặt hàng của khách để so sánh với điều kiện thực tế vận hành. Hướng dẫn của NIST về AI công nghiệp cũng nhấn mạnh tầm quan trọng của việc đánh giá tính liên quan, chính xác, đại diện, thiếu dữ liệu và các sự kiện hiếm trong dữ liệu đầu vào.

Chấp nhận đầu ra “không thể dự đoán”

Nếu dự kiến nhập vật tư bị bỏ trống, MES mất kết nối, đơn hàng và lệnh sản xuất không đối chiếu được, tốt hơn nên trả về “không thể đánh giá/cần xác nhận” thay vì ép ra 0% hay 100%. Không chỉ tỷ lệ thiếu, mà còn hiển thị mục nào cần thiết cho quyết định bị thiếu. Với sản phẩm hoặc dây chuyền mới có ít dữ liệu quá khứ, cũng không nên trả xác suất với độ tự tin như sản phẩm cũ. Quy tắc xác định ngoài phạm vi và luồng xác nhận thủ công cần được quyết định trước khi chọn mô hình.

Phân biệt xác suất trễ và đề xuất hành động

Nhiệm vụ của mô hình dự đoán là, tại thời điểm đánh giá đã định nghĩa, chỉ ra khả năng đơn hàng không kịp hạn. Ngược lại, quyết định biện pháp nào cần cân nhắc ràng buộc chất lượng, năng lực thiết bị, nhân lực, vật tư, ưu tiên khách hàng, chi phí, ảnh hưởng đến đơn hàng khác – là một vấn đề khác. IBM phân biệt phân tích dự đoán và phân tích đề xuất, trong đó phân tích đề xuất liên quan đến lựa chọn hành động như lập kế hoạch, lịch trình, tồn kho, logistics. Tuy nhiên, không nên dùng mô tả của IBM như bằng chứng rằng bất kỳ sản phẩm dự đoán trễ nào cũng hiệu quả.

Ở giai đoạn đầu, không nên cam kết thay đổi kế hoạch tự động ngay, mà nên thiết kế màn hình dự đoán kèm giải thích và đề xuất can thiệp. Người phụ trách có thể chọn “đẩy sớm vật tư”, “xem xét dây chuyền thay thế”, “chuyển phương án vận chuyển”, “đề xuất giao từng phần cho khách” v.v., và kiểm tra khả năng thực hiện. Lý do AI đưa ra không phải là bằng chứng nhân quả. Nếu chỉ dựa vào tương quan “nhiều đơn hàng rủi ro cao bị thiếu vật tư”, không nên khẳng định chắc chắn rằng thúc giục vật tư sẽ đảm bảo giao hàng.

Cảnh báo thay đổi theo vai trò và hạn chót

Cùng một rủi ro, quản lý sản xuất quan tâm đến trình tự công đoạn, mua hàng quan tâm đến vật tư đến, bảo trì quan tâm đến phục hồi thiết bị, kinh doanh quan tâm đến điều kiện thỏa thuận với khách. Màn hình cần hiển thị dòng đơn hàng, ngày hứa, thời điểm đánh giá, tiến độ hiện tại, dữ liệu còn thiếu, người phụ trách, hạn chót quyết định tiếp theo. Nếu chỉ sắp xếp theo mức độ nguy hiểm, sẽ lẫn lộn giữa các vụ có thể và không thể can thiệp. Các vụ không còn thời gian can thiệp cần chuyển sang xử lý liên hệ khách và phương án thay thế, định nghĩa rõ trạng thái chuyển đổi.

Liên hệ khách hàng cần phê duyệt riêng. Không triển khai cấu hình AI tự động gửi thông báo “sẽ trễ” cho khách mà không xác nhận điều kiện hợp đồng và quyết định của kinh doanh. Trong kiểm thử, cần xác minh ai phê duyệt báo giá lại, ai truyền đạt ra ngoài, lưu thời gian/nội dung liên hệ và ngày tái thỏa thuận ở đâu. Cũng cần xây dựng quy trình sửa khi dự đoán sai. Không nên gộp thao tác đóng cảnh báo với thao tác hoàn thành cam kết với khách.

Kiểm thử nghiệm thu không chỉ dừng ở “độ chính xác”

Chỉ số đánh giá AI là cần thiết, nhưng chỉ một con số tổng hợp không đủ để quyết định đặt hàng. Nếu giai đoạn có ít vụ trễ, chỉ cần trả lời “đúng hạn” cho tất cả cũng có thể đạt độ chính xác cao. Cần liệt kê số vụ bỏ sót, cảnh báo sai, hiệu quả của cảnh báo ưu tiên, hiệu chỉnh xác suất, thời gian từ đánh giá đến hành động, đồng thời xem xét gánh nặng hiện trường và ảnh hưởng khách hàng. ISO 22400-1 đưa ra khung trung lập về định nghĩa, cấu trúc, sử dụng KPI vận hành sản xuất, nhưng không quy định ngưỡng đạt cho AI dự đoán giao hàng. Ngưỡng cần xác định dựa trên giao hàng, chi phí, nhân lực của từng doanh nghiệp.

Giai đoạn đầu của kiểm thử nghiệm thu là tái hiện thời điểm quá khứ. Phục hồi dữ liệu nhìn thấy tại từng thời điểm đánh giá, kiểm tra không lẫn thông tin biết sau này. Giai đoạn hai là vận hành song song tại hiện trường. AI chỉ ghi nhận dự đoán, không thay đổi kế hoạch chính thức hay liên hệ khách. Người phụ trách tiếp tục công việc thường ngày, ghi lại cơ sở quyết định. Giai đoạn ba, thử can thiệp có phê duyệt người thật trên một số dây chuyền và đơn hàng giới hạn. Quyết định mở rộng phạm vi không chỉ dựa vào thành tích mô hình, mà còn dựa vào độ ổn định tích hợp dữ liệu, thời gian xử lý, gánh nặng do cảnh báo sai, và dấu vết kiểm toán.

Xây dựng từng trường hợp kiểm thử tái hiện tại thời điểm phán định

Trong kiểm thử tái hiện, chỉ đơn giản quan sát lại các trường hợp bị trễ sau khi sự việc đã xảy ra là không đủ. Cần cố định thời điểm phán định cho từng chi tiết đơn hàng, và chỉ đọc lại các phiên bản ERP và MES đã được đăng ký đến thời điểm đó. Phiếu kiểm thử sẽ liệt kê số đơn hàng và số chi tiết, phiên bản ngày hẹn giao, lệnh sản xuất và phiên bản quy trình, thời điểm phát sinh và thời điểm đăng ký của từng sự kiện, phiên bản mô hình, kết quả dự báo và kết quả cuối cùng. Đối với các hệ thống không thể trả dữ liệu đầu vào về cùng một thời điểm, điều kiện chấp nhận là phải thiết kế để lưu lại ít nhất snapshot hàng ngày và log chỉnh sửa. Nếu thiếu cả hai, dù có kết quả tốt với dữ liệu quá khứ thì cũng không thể xác minh được “dự báo tại thời điểm đó”.

Lấy ví dụ cụ thể, chuẩn bị một chuỗi thời gian giả lập: AI phán định lúc 08:00 thứ Hai, bộ phận kinh doanh tái thỏa thuận ngày giao với khách hàng lúc 10:00 cùng ngày, và hiện trường đăng ký bổ sung thực tế sản xuất của ngày Chủ nhật vào lúc 11:00. Trong dự báo lúc 08:00 thứ Hai, chỉ sử dụng ngày hẹn giao cũ, không sử dụng ngày hẹn giao mới lúc 10:00 hay dữ liệu thực tế lúc 11:00. Trong dự báo ngày thứ Ba, sử dụng ngày hẹn giao đã tái thỏa thuận và dữ liệu thực tế đã có. Nếu thực hiện ghi đè dòng dữ liệu cũ bằng ngày hẹn giao mới và thay đổi cả nhãn đúng/sai thì coi là không đạt yêu cầu. Yêu cầu phải lưu lại các phiên bản trước và sau khi tái thỏa thuận, và có thể truy vết được việc trễ liên quan đến phiên bản nào.

Một trường hợp khác, giả sử truyền thông MES bị gián đoạn từ 07:30 đến 09:00 thứ Hai, nhưng thiết bị thực tế đã phục hồi lúc 07:45. Tại thời điểm 08:00, sự kiện phục hồi chưa được hệ thống nhận, nên AI không thể coi là đã biết việc phục hồi. Màn hình lúc 08:00 phải hiển thị “thông tin cũ do mất kết nối”, và việc phát cảnh báo hay không, hoặc không thể phán định, phải tuân theo quy tắc nghiệp vụ đã định trước. Sau khi kết nối trở lại lúc 09:00, hệ thống sẽ tiếp nhận sự kiện mới nhất và lưu lại sự thay đổi của cảnh báo trước đó. Các kiểm thử tương tự cũng được mở rộng cho các trường hợp như giao hàng từng phần, chia nhỏ lệnh sản xuất, thay đổi kế hoạch nhập vật tư, hoặc tái phán định kiểm tra.

So sánh bỏ sót và cảnh báo sai trong cùng khung xử lý

Khi so sánh mô hình, điều quan trọng là không để AI chỉ chọn những ngày hoặc trường hợp thuận lợi cho mình. Cần chạy cả quy tắc truyền thống và AI trên cùng một khoảng thời gian, cùng chi tiết đơn hàng, cùng thời điểm phán định, cùng định nghĩa đúng/sai về trễ. Trước tiên xác định số lượng cảnh báo mà nhân viên có thể kiểm tra mỗi ngày, sau đó so sánh số trường hợp trễ thực tế được phát hiện, phát hiện trước bao nhiêu ngày, và số cảnh báo sai. Điều này nhằm tránh so sánh theo hướng phương pháp nào phát ra nhiều cảnh báo hơn thì có lợi.

Giả sử nhân viên chỉ có thể kiểm tra 20 trường hợp mỗi ngày. Con số 20 này chỉ là giả định để minh họa. Cả quy tắc truyền thống và AI đều chỉ xét 20 trường hợp hàng đầu, rồi so sánh số trường hợp trễ được phát hiện và số trường hợp có thể can thiệp. Nếu AI phát hiện trễ sớm nhưng tất cả đều đã quá hạn giao hàng thì hiệu quả cũng hạn chế. Ngược lại, nếu cảnh báo sai nhưng lại giúp phát hiện và sửa lỗi nhập liệu thì nên ghi nhận như một hiệu quả nghiệp vụ riêng, không tính vào thành tích dự báo. Cũng cần lưu lại các trường hợp nhân viên vắng mặt hoặc khác biệt ca làm trong phiếu kiểm thử, để kiểm tra sự khác biệt giữa khung xử lý lý thuyết và năng lực xử lý thực tế.

Nếu điều chỉnh ngưỡng cảnh báo dựa trên dữ liệu kiểm thử sau này, thì không sử dụng cùng dữ liệu đó làm căn cứ đánh giá cuối cùng. Phải tách riêng giai đoạn xác định ngưỡng và giai đoạn xác nhận cuối cùng. Cũng cần thể hiện rõ các thiên lệch như cảnh báo tập trung vào một số khách hàng nhất định hoặc bỏ sót sản phẩm mới. Việc đánh giá đạt/không đạt không chỉ dựa vào “tỷ lệ đúng của AI trên bao nhiêu phần trăm”, mà còn phải xét đến tốc độ can thiệp thực tế tại hiện trường, số lượng cảnh báo có thể xử lý, và cả việc hoàn thành liên lạc với khách hàng.

Thay thế số liệu minh họa bằng dữ liệu thực tế doanh nghiệp

Giả sử mỗi tháng có 1.000 dòng đơn hàng, thực tế trễ 50 dòng, cảnh báo mà người phụ trách có thể kiểm tra mỗi ngày là 20. Đây chỉ là số minh họa. Trước khi quyết định triển khai, cần kiểm tra tỷ lệ trễ, số vụ có thể kiểm tra, thời gian cần thiết để xử lý trên dữ liệu thực tế doanh nghiệp. Khi so sánh mô hình, dùng cùng tháng và thời điểm đánh giá, lấy quy tắc đơn giản “cảnh báo nếu ngày hoàn thành dự kiến vượt ngày hứa” làm đường cơ sở. Kiểm chứng AI có phát hiện được vụ khả thi sớm hơn hoặc với ít cảnh báo thừa hơn không.

Nếu “muốn phát hiện thêm một vụ trễ” mà phát sinh hàng trăm cảnh báo mỗi ngày, người phụ trách sẽ không kiểm tra hết. Ngược lại, nếu lọc cảnh báo quá kỹ sẽ bỏ sót vụ quan trọng của khách lớn. Cần phân biệt bỏ sót theo khách ưu tiên, sản phẩm, điều kiện hứa, không chỉ dựa vào trung bình tổng thể. Thay đổi ngưỡng cùng với năng lực xử lý của người phụ trách để xác định điểm cân bằng nghiệp vụ.

Không nhầm lẫn “hiệu quả dự đoán” và “hiệu quả can thiệp”

Nếu AI dự đoán trễ, người phụ trách đẩy sớm vật tư và giao đúng hạn, nhìn bề ngoài dự đoán có vẻ sai. Nhưng có thể kết quả đã thay đổi nhờ can thiệp. Cần ghi lại riêng rủi ro lúc dự đoán, nội dung và thời điểm can thiệp, các vụ tương tự không can thiệp, và kết quả cuối cùng. Nếu chỉ đo độ chính xác mô hình sau khi đã triển khai AI vào hiện trường, đánh giá sẽ bị lệch. Hiệu quả triển khai nên được theo dõi riêng: phát hiện sớm, thực hiện can thiệp, kết quả giao hàng, chất lượng liên hệ khách.

Các mục cần ghi rõ trong RFP và phân chia trách nhiệm

Trong đặc tả đặt hàng, cần mô tả trước màn hình dashboard: dòng đơn hàng nào, khi nào đánh giá, dùng thông tin nào, ai hành động. “Có thể tích hợp ERP/MES”, “AI chính xác cao” không đủ để so sánh đề xuất các nhà cung cấp. Cần ẩn danh mẫu dữ liệu thực tế, đưa ra các bài kiểm thử gồm thiếu dữ liệu, sửa đổi, giao từng phần, tái gia công với cùng điều kiện. Không quy định cứng thời gian lịch sử hay chi phí học, mà yêu cầu báo giá dựa trên độ chi tiết và tốc độ thay đổi dữ liệu.

Ngay cả với các mục nhà cung cấp trả lời “có thể dự đoán”, cần xác nhận API, license, lưu lịch sử của ERP/MES hiện có. Nếu có công đoạn không thể cung cấp dữ liệu, cần xác định phạm vi giai đoạn đầu loại trừ công đoạn đó. Không nên trì hoãn tích hợp vì AI khó, mà cần minh bạch hóa trước những gì không thể tích hợp. Khung quản lý rủi ro AI của NIST là khung tham khảo tự nguyện để cân nhắc độ tin cậy từ thiết kế đến vận hành/đánh giá. Bảng kiểm thử trong bài này là đề xuất thực tiễn tham khảo khung đó, không phải tiêu chuẩn bắt buộc.

Lưu ý khi triển khai tại nhà máy Thái Lan

Tại các cơ sở sản xuất ở Thái Lan, giao diện hiện trường có thể pha trộn tiếng Thái với tiếng Nhật/Anh cho trụ sở. Nếu chỉ dịch phần hiển thị rủi ro mà không đồng nhất định nghĩa ngày hứa, lý do ngừng thiết bị, thông báo cho người phụ trách, cùng một vụ việc có thể bị xử lý khác nhau. Cần lập bảng thuật ngữ gồm nguyên ngữ, ý nghĩa nghiệp vụ, hiển thị trên màn hình, và lập phiếu kiểm thử bằng ngôn ngữ người phê duyệt đọc được. Thử nghiệm cả quy trình chuyển ca, nghỉ lễ trên lịch làm việc thực tế.

Khi kết nối từ nhà máy Thái Lan về ERP trụ sở, luôn hiển thị thời điểm đồng bộ cuối cùng khi mất kết nối. Không được hiển thị cảnh báo dựa trên dữ liệu cũ như dự đoán mới. Quyền truy cập cần phân biệt phạm vi kinh doanh xem thông tin khách, quản lý sản xuất xem lệnh, nhà cung cấp ngoài xử lý dữ liệu kiểm thử. Việc xử lý thông tin cá nhân, hợp đồng cần xác nhận riêng theo quy định nội bộ và pháp luật.

Sau triển khai: Giám sát cả mô hình và nghiệp vụ

Sau khi vận hành, không chỉ giám sát mô hình dự đoán. Cần theo dõi tỷ lệ liên kết ERP/MES, số sự kiện đến trễ, số vụ không thể đánh giá, thời gian mở cảnh báo, chờ phê duyệt can thiệp, thời gian đến khi liên hệ khách. Khi có sản phẩm mới, thay đổi công đoạn, thay đổi nguồn cung, cần so sánh với dữ liệu quá khứ, điều chỉnh ngưỡng hoặc mô hình nếu cần. Khi thay đổi phiên bản mô hình, cần giải thích được sự khác biệt đầu ra cho cùng vụ việc.

Trong các cuộc họp cải tiến, không chỉ hỏi “dự đoán đúng không” mà còn “ai đã làm được gì”. Nếu vụ rủi ro cao mà không thể can thiệp, nguyên nhân là năng lực thiết bị, chờ phê duyệt, hay hết hạn thương lượng với khách? Hướng đầu tư tiếp theo sẽ khác nhau. Đôi khi, sửa quy tắc nhập liệu, cách xác nhận vật tư, phân chia trách nhiệm liên hệ khách còn hiệu quả hơn tái học AI.

So sánh trước/sau khi thay đổi mô hình bằng cùng tiêu chí

Khi thay mô hình mới, không chỉ thay kết quả dự đoán, mà chạy song song phiên bản cũ và mới với cùng đầu vào tại thời điểm đánh giá. Kiểm tra số cảnh báo tăng/giảm ở dòng đơn hàng nào, số vụ không thể đánh giá tăng ở nhóm sản phẩm nào. Nếu tỷ lệ đúng tổng thể tăng trong tháng thay đổi cấu trúc sản phẩm, nhưng bỏ sót khách quan trọng, không thể coi là đạt. Ghi lại lý do thay đổi, người phê duyệt, thời điểm áp dụng, cách quay lại, và lưu lịch sử cảnh báo trước khi cập nhật mô hình.

Để không đổ lỗi cho mô hình về vấn đề vận hành, hàng ngày cần kiểm tra trước độ trễ nhập liệu và lỗi tích hợp. Nếu ngày hứa trên ERP đã cập nhật mà lệnh MES vẫn phiên bản cũ, dù AI hoạt động đúng, giao diện vẫn mâu thuẫn. Hàng tuần kiểm tra trạng thái xử lý cảnh báo và kết quả can thiệp, hàng tháng xem lại ngưỡng và phạm vi đối tượng, điều chỉnh theo chu kỳ nghiệp vụ doanh nghiệp. Tần suất chỉ là ví dụ, cần xác định theo hệ thống và hợp đồng khách hàng.

Xác định rõ phạm vi bắt đầu nhỏ

Thực nghiệm ban đầu nên giới hạn ở nhóm sản phẩm/dây chuyền có định nghĩa ngày hứa rõ ràng, theo dõi được thực tế công đoạn, để dễ đánh giá. Tuy nhiên, nếu chỉ chọn phạm vi hầu như không có trễ, sẽ không biết có dùng được cho vụ khó không. Nên chọn phạm vi gồm cả vụ bình thường, vụ trễ, nhập liệu bổ sung, tái gia công, và chỉ rõ dây chuyền/sản phẩm ngoài phạm vi. Không ngoại suy kết quả thực nghiệm cho toàn bộ nhà máy, mà kiểm tra lại định nghĩa dữ liệu, ca làm, điều kiện khách ở phạm vi mở rộng tiếp theo.

Cần xác định trước điều kiện kết thúc. Ví dụ, nếu số vụ không liên kết được nhiều hơn dự kiến, nên quay lại hoàn thiện bảng đối chiếu ID thay vì điều chỉnh mô hình. Nếu người phụ trách không xử lý hết cảnh báo, cần thiết kế lại đối tượng/thứ tự thông báo. Nếu dự đoán rất tốt mà liên hệ khách bị chờ phê duyệt, nên thay đổi quy trình vận hành. Đặt cả điều kiện thành công và điều kiện dừng vào tờ trình và phiếu nghiệm thu để tránh chuyển sang vận hành chính thức khi thực nghiệm chưa rõ ràng.

Lộ trình AI/ML cho sản xuất thông minh do NIST công bố năm 2026 cũng chỉ ra các thách thức về dữ liệu công nghiệp phức tạp, tích hợp hệ thống dị chủng, độ tin cậy và khả năng giải thích. Đây không phải là đảm bảo cho phương pháp dự đoán trễ hay tỷ lệ cải thiện cụ thể. Khi quyết định triển khai, cần lưu lại bằng chứng về cách xử lý các thách thức đó trong hợp đồng dữ liệu và kiểm thử nghiệm thu nghiệp vụ của doanh nghiệp.

Câu hỏi thường gặp: Cần bao nhiêu năm dữ liệu lịch sử để triển khai AI dự đoán trễ giao hàng?

Không có con số cố định. Cần xem nhóm sản phẩm, mùa cao điểm, thay đổi công đoạn, số vụ trễ thực tế có đủ cho học và kiểm thử không. Dữ liệu đại diện, ghi nhận đúng nghĩa với công đoạn hiện tại quan trọng hơn số lượng lịch sử cũ. Trước tiên xác định nhãn đúng/sai và thời điểm đánh giá, tạo đường cơ sở với dữ liệu hiện có, nếu thiếu thì lập kế hoạch thu thập bổ sung.

Câu hỏi thường gặp: Có thể bắt đầu chỉ với ERP không?

Chỉ với ERP, đôi khi có thể tạo cảnh báo đơn giản từ ngày hứa, số lượng đặt, phân bổ vật tư, ngày hoàn thành kế hoạch. Tuy nhiên, nếu thực tế công đoạn bị trễ, khả năng dự đoán sớm và giải thích sẽ hạn chế. Nên bắt đầu nhỏ với phạm vi rõ ràng, sau đó so sánh cùng điều kiện kiểm thử khi bổ sung sự kiện công đoạn từ MES để xem thay đổi số vụ bỏ sót và cảnh báo sai.

Câu hỏi thường gặp: Nếu xác suất cao có nên tự động thông báo cho khách?

Không. Xác suất chỉ là cơ sở quyết định, không phải quyền thay đổi cam kết với khách. Cần xác nhận điều kiện giao hàng, phương án thay thế, phê duyệt nội bộ, khả năng chấp nhận của khách, và người có thẩm quyền sẽ liên hệ. Trong kiểm thử nghiệm thu, tách riêng hỗ trợ soạn nội dung thông báo và phê duyệt gửi, kiểm tra lịch sử và quy trình sửa đổi.

Kết luận: Đặt điều kiện nghiệm thu vào nghiệp vụ

AI dự đoán trễ giao hàng không chỉ có giá trị khi hiển thị xác suất trễ. Cần kiểm thử toàn diện: định nghĩa cam kết, thời điểm đánh giá, phòng ngừa rò rỉ dữ liệu, tích hợp ERP/MES, xử lý khi không thể đánh giá, can thiệp của người phụ trách, liên hệ khách. Đánh giá cùng điều kiện với đường cơ sở, xác định có phát hiện được vụ hữu ích trong số lượng và thời gian hiện trường có thể xử lý. Đầu tư AI nâng cao năng suất nhà máy chỉ có thể đánh giá khi kết nối số liệu mô hình với kết quả nghiệp vụ.

Ngay từ giai đoạn sắp xếp các mục RFP hoặc kiểm thử nghiệm thu nhỏ với dữ liệu đơn hàng và thực tế công đoạn của doanh nghiệp, bạn có thể liên hệ với TOMAS TECH. Ngay cả khi chưa xác định rõ hệ thống mục tiêu hay định nghĩa ngày giao hàng cần đánh giá, chúng tôi vẫn có thể hỗ trợ.

Tham khảo

1. ISA, ISA-95 Standard: Enterprise-Control System Integration — Khung trao đổi thông tin giữa ERP và vận hành sản xuất. Không quy định yêu cầu AI cụ thể.
2. ISO, ISO 22400-1:2014 — Tổng quan về khái niệm, thuật ngữ, sử dụng KPI quản lý vận hành sản xuất. Không quy định ngưỡng đạt cho AI cụ thể.
3. NIST, How to Find the Right Balance of Data for Your Industrial AI System — Xem xét tính liên quan, chính xác, đại diện, thiếu dữ liệu trong AI công nghiệp.
4. NIST, AI Risk Management Framework — Khung quản lý rủi ro AI tự nguyện cho thiết kế, sử dụng, đánh giá.
5. IBM, Prescriptive analytics: Manage manufacturing costs and improve ROI — Quan điểm nhà cung cấp về sự khác biệt giữa dự đoán và lựa chọn hành động.
6. IBM Research, Continuous prediction of manufacturing performance throughout the production lifecycle — Ví dụ nghiên cứu cập nhật dự đoán trong quá trình sản xuất (đối tượng là chất lượng sản phẩm, không phải hiệu quả dự đoán trễ giao hàng).
7. NIST, 2026 Roadmap on Artificial Intelligence and Machine Learning for Smart Manufacturing — Tài liệu gốc năm 2026 tổng hợp thách thức về dữ liệu công nghiệp, tích hợp hệ thống dị chủng, độ tin cậy.

*Chú thích biên tập: Các kịch bản, thời điểm, số lượng, ngưỡng trong bài chỉ là giả định minh họa cho thiết kế. Không phải số liệu thống kê đảm bảo kết quả.*