Câu hỏi đầu tiên khi cân nhắc AI cải thiện tỷ lệ thành phẩm hầu như luôn là “độ chính xác đạt bao nhiêu phần trăm”. Nhưng chỗ dự án thực sự dừng lại nằm trước cả mô hình. Hồ sơ lỗi và hồ sơ công đoạn không nối được với nhau bằng cùng một khóa. Chỉ vì đúng một điểm đó, phần lớn các khoản đầu tư kết thúc mà không chạm tới kết quả. Bài viết này lấy khóa liên kết và mã lỗi làm trục, bóc tách bằng con số tới tận 5 tầng chi phí và số tháng thu hồi vốn, ở độ chi tiết đủ để bạn mở dữ liệu của chính nhà máy mình ra kiểm chứng.
AI cải thiện tỷ lệ thành phẩm làm được gì — khác biệt với AI kiểm tra ngoại quan
Những công nghệ vẫn bị gộp chung dưới một cái tên “AI cho nhà máy” thực chất là ba thứ khác nhau. Nếu lấy báo giá trong lúc ba thứ đó còn lẫn vào nhau, cái mua về sẽ lệch khỏi chỉ số mà nhà máy muốn dịch chuyển.
Thứ nhất là nhóm phát hiện. Từ ảnh chụp bằng camera, hệ thống nhận diện vết xước, vết mẻ và dị vật. AI kiểm tra ngoại quan thuộc nhóm này. Thứ hai là nhóm dự đoán. Từ dữ liệu công đoạn như nhiệt độ, áp suất, dòng điện, mô men xoắn, hệ thống đọc trước những lỗi sắp phát sinh. Thứ ba là nhóm xác định nguyên nhân. Hệ thống đối chiếu lỗi trong quá khứ với dữ liệu công đoạn để khoanh lại xem điều kiện nào đang tác động lên lỗi. Đây là lĩnh vực thường được gọi là phân tích yếu tố hoặc phân tích nguyên nhân gốc.
Thứ đáng được gọi là AI cải thiện tỷ lệ thành phẩm chỉ gồm nhóm thứ hai và nhóm thứ ba. Nhóm phát hiện, tức nhóm thứ nhất, không phải là công nghệ nâng tỷ lệ thành phẩm.
| Nhóm | Đầu vào chính | Câu trả lời đưa ra | Chỉ số dịch chuyển |
|---|---|---|---|
| 1. Nhóm phát hiện (AI kiểm tra ngoại quan) | Ảnh chụp sản phẩm | Sản phẩm này là hàng đạt hay hàng lỗi | Tỷ lệ lọt lỗi, giờ công kiểm tra |
| 2. Nhóm dự đoán | Chuỗi thời gian của dữ liệu công đoạn | Với điều kiện này thì lỗi có khả năng phát sinh không | Tỷ lệ phát sinh lỗi (đón đầu) |
| 3. Nhóm xác định nguyên nhân | Dữ liệu công đoạn cộng lịch sử lỗi | Điều kiện nào đang tạo ra lỗi | Tỷ lệ phát sinh lỗi (căn cơ) |
Điều cần nắm ở bảng trên là ô “chỉ số dịch chuyển” của nhóm thứ nhất. Cái được cải thiện khi đưa AI kiểm tra ngoại quan vào là tỷ lệ hàng lỗi bị bỏ sót và đi ra tới khách hàng, tức tỷ lệ lọt lỗi, cùng với giờ công của những người đang kiểm tra bằng mắt. Bản thân lỗi vẫn tiếp tục phát sinh đúng chừng đó. Độ chính xác kiểm tra càng cao thì số hàng lỗi bị bắt lại trong nội bộ càng tăng chứ không giảm. Chừng nào tỷ lệ thành phẩm còn được định nghĩa là tỷ lệ hàng đạt trên lượng đầu vào, thì việc đưa AI kiểm tra ngoại quan vào sẽ không làm tỷ lệ đó tăng lên. Các tiêu chí đánh giá chi tiết đã được sắp xếp riêng tại bài Đánh giá khi đưa AI kiểm tra ngoại quan vào nhà máy, nhưng chỉ cần tách bạch ngay từ đầu rằng mục tiêu là ngăn lọt lỗi hay là chặn phát sinh lỗi, bạn sẽ thấy hai thứ này vốn không đứng chung một sân để so sánh.
Nhóm thứ hai và nhóm thứ ba có quan hệ như hai anh em cùng đứng trên một nền tảng dữ liệu. Chỉ khi nhóm thứ ba chỉ ra được rằng “lỗi xuất hiện khi rơi vào điều kiện này”, thì dự đoán của nhóm thứ hai mới trở thành thông tin để hiện trường hành động được. Ngược lại, nếu bỏ qua nhóm thứ ba mà chỉ làm nhóm thứ hai, kết quả sẽ là cảnh báo có kêu nhưng không ai biết phải sửa cái gì. Hiện trường chỉ nhìn cảnh báo trong vài tuần đầu, sau đó thì thôi không nhìn nữa.
Có lý do khiến ba nhóm này dễ bị lẫn vào nhau. Nhóm phát hiện có nhiều ví dụ triển khai và phần trình diễn thì rất dễ hiểu. Cứ đặt một sản phẩm lỗi trước camera là kết quả đánh giá hiện ra ngay tại chỗ. Nhóm thứ hai và thứ ba không thể trình bày theo cách đó. Phải liên kết dữ liệu công đoạn rồi đối chiếu với lỗi trong quá khứ mới ra được kết quả, nên tại buổi đề xuất không có gì chạy được để đưa ra xem. Hệ quả là một dự án khởi đầu từ câu chuyện tỷ lệ thành phẩm lại dần bị thay thế bằng đề xuất kiểm tra ngoại quan ở giữa chừng.
Còn một việc nữa cần thống nhất trong nội bộ trước. Đó là định nghĩa của chính con số mà công ty bạn đang gọi là tỷ lệ thành phẩm. Nhà máy đang nhìn theo số hàng đạt cuối cùng trên số lượng đầu vào, hay nhân dồn tỷ lệ đi qua của từng công đoạn? Hàng đã sửa lại rồi thành hàng đạt thì có được tính vào tử số không? Nếu đặt mục tiêu cải thiện trong lúc mỗi bộ phận vẫn hiểu một kiểu, tới bước đo hiệu quả các con số sẽ không khớp nhau. Ở những nhà máy tính hàng sửa lại vào hàng đạt, hiệu quả sẽ xuất hiện dưới dạng giảm giờ công sửa hàng chứ tỷ lệ thành phẩm không nhúc nhích, nên đặt chỉ số đo về phía giờ công ngay từ đầu sẽ chính xác hơn.

Khi nhận được báo giá, thứ cần kiểm tra đầu tiên không phải số tiền mà là chủ ngữ. Nếu chủ ngữ của đề xuất là “hình ảnh” thì đó là khoản đầu tư vào tỷ lệ lọt lỗi. Nếu chủ ngữ là “dữ liệu công đoạn” thì mới có khả năng đó là khoản đầu tư vào tỷ lệ thành phẩm. Nếu bản đề xuất trộn cả hai, hãy yêu cầu nhà cung cấp tách chi tiết chi phí ra thành phần nhóm thứ nhất và phần nhóm thứ hai cùng nhóm thứ ba. Chỉ thêm một thao tác này thôi, tình huống về sau phải nói “hiệu quả khác với những gì tôi tưởng” gần như biến mất.
Vì sao AI cải thiện tỷ lệ thành phẩm không chạy — đứt gãy giữa 70% thu thập và 40% hiệu quả
Sách trắng ngành chế tạo bản 2026 của Nhật Bản, được Nội các thông qua ngày 29 tháng 5 năm 2026, có một cặp số nêu thẳng vấn đề này. Số doanh nghiệp đang thu thập dữ liệu trong quá trình sản xuất là khoảng 70%. Trong khi đó, số doanh nghiệp sử dụng được dữ liệu ấy và thu về hiệu quả chỉ dừng ở khoảng 40%.
Chênh lệch là khoảng 30%. Nhóm 30% này không phải là nhóm không thu thập dữ liệu. Đó là nhóm có thu thập nhưng không nối được. Cảm biến đã gắn. Hồ sơ kiểm tra cũng có. Báo cáo sản xuất hằng ngày vẫn được lưu. Vậy mà phân tích không thành hình.
Khi mổ xẻ nguyên nhân ngay tại hiện trường, các điểm đứt gãy thu lại còn ba.
| Đứt gãy | Triệu chứng | Cách kiểm tra |
|---|---|---|
| 1. Độ chi tiết của mã lỗi | Số lượng lớn dồn vào “Khác” và “Lỗi ngoại quan” | Sắp xếp số vụ theo từng mã lỗi trong một năm gần nhất theo thứ tự giảm dần |
| 2. Khóa liên kết | Hồ sơ lỗi và hồ sơ công đoạn không có ID chung | Mở cả hai file CSV và xem có tồn tại dù chỉ một tên cột giống nhau hay không |
| 3. Đồng bộ thời gian | Đồng hồ của máy kiểm tra, PLC và MES lệch nhau | Truy cùng một sự kiện trên cả ba hệ thống rồi so sánh thời điểm ghi nhận |
Trong ba đứt gãy đó, chỗ dễ khiến khoản đầu tư trở nên vô nghĩa nhất là đứt gãy thứ hai. Đứt gãy thứ nhất chỉ cần làm lại bảng mã lỗi là kỳ sau bắt đầu cải thiện được. Đứt gãy thứ ba, về mặt kỹ thuật, dựng một máy chủ NTP rồi đồng bộ toàn bộ các hệ thống là xong. Nhưng đứt gãy thứ hai là câu chuyện thay đổi chính cách dữ liệu được nắm giữ, tức là phải động vào quy cách đầu ra của máy kiểm tra, PLC và MES vốn đã đang chạy. Nếu tới khi dự án triển khai đã khởi động mới phát hiện ra rằng “không nối được”, nhà máy sẽ phải quay lại làm lại thiết kế từ đầu.
Việc đồng bộ thời gian ở đứt gãy thứ ba hay bị xem nhẹ so với mức ảnh hưởng thật của nó. Ở một công đoạn có nhịp sản xuất vài chục giây, nếu đồng hồ máy kiểm tra và đồng hồ PLC lệch nhau vài phút, thì điều kiện công đoạn được gắn cho một sản phẩm lỗi sẽ hóa ra là điều kiện của sản phẩm bên cạnh, hoặc của sản phẩm kế bên nữa. Tình huống xảy ra là nhà máy đã gán ID tới tận từng sản phẩm, nhưng điều kiện gắn vào lại thuộc về một sản phẩm khác. Nếu độ lệch cố định thì về sau vẫn bù lại được bằng offset, còn những hệ thống mà người phụ trách định kỳ chỉnh đồng hồ bằng tay thì độ lệch không ổn định nên không bù được. Cần kiểm tra theo từng hệ thống xem cơ chế đồng bộ đã có hay chưa.

Việc có thể kiểm tra ngay ngày mai là đây. Xin bộ phận kiểm tra xuất hồ sơ lỗi của một năm, xin bộ phận kỹ thuật sản xuất xuất dữ liệu công đoạn của đúng một năm đó, cả hai đều dưới dạng CSV. Mở hai file cạnh nhau và tìm những cột cùng có mặt ở cả hai bên. Nếu chỉ có ngày tháng là điểm chung, nhà máy của bạn đang nằm ở phía khoảng 30% kia. Việc kiểm tra này cần nửa ngày và không cần gọi nhà cung cấp AI nào cả.
Thiết kế khóa liên kết — ba tầng lô, đơn chiếc và thời điểm
Khóa liên kết có ba tầng. Bạn nắm tới tầng nào thì phạm vi những câu hỏi trả lời được sẽ do đó mà định ra.
| Tầng | Ví dụ về khóa | Câu hỏi trả lời được | Gánh nặng thu thập |
|---|---|---|---|
| Tầng lô | Số lô, số lệnh sản xuất | Lô nào bị lỗi nhiều | Thấp (nhiều nơi đã có sẵn) |
| Tầng đơn chiếc | Số serial sản phẩm, mã 2D | Sản phẩm nào bị lỗi, sản phẩm đó đã đi qua máy số mấy | Trung bình (thêm việc đánh số và đọc mã) |
| Tầng thời điểm | Dấu thời gian chính xác tới giây | Đúng khoảnh khắc sản phẩm đó được gia công, điều kiện ra sao | Trung bình (điều kiện tiên quyết là đồng bộ thời gian) |
Thứ mà phần lớn nhà máy đang nắm chỉ là tầng lô. Và chỉ với tầng lô thì không xác định được nguyên nhân. Lý do không phải chuyện tinh thần thái độ, mà là vấn đề cấu trúc của dữ liệu.
Giả sử một lô gồm 2,000 sản phẩm. Dây chuyền mô hình trong bài này có tỷ lệ thành phẩm hiện tại là 96.4%, nên tỷ lệ lỗi là 3.6%, tức mỗi lô có 72 sản phẩm lỗi. Việc chỉ có hồ sơ ở mức lô đồng nghĩa với chuyện toàn bộ 2,000 sản phẩm này mang đúng cùng một bộ giá trị điều kiện công đoạn. Cả 72 sản phẩm lỗi lẫn 1,928 sản phẩm đạt, trên dữ liệu, đều gắn vào cùng một dòng ghi “nhiệt độ 185 độ C, áp suất 4.2 MPa, máy số A”.
Phân tích yếu tố về bản chất là công việc tìm ra điểm khác nhau trong phân bố của các biến giải thích giữa hàng đạt và hàng lỗi. Nếu hàng đạt và hàng lỗi mang cùng một giá trị, thì dù dùng thống kê hay dùng AI cũng không phát hiện được khác biệt. Mang mô hình nào tới thì kết quả vẫn thế. Độ phân giải của phân tích không thể vượt quá độ phân giải của hồ sơ.
Khi nắm tới tầng đơn chiếc, tình hình đổi khác. Nhà máy nhìn thấy được 72 sản phẩm lỗi ấy đang lệch về máy số A, hay đang dồn vào một khung giờ nhất định, hay đang tập trung ở một vị trí cavity cụ thể. Tới thời điểm này, nhiều thứ con người nhìn bằng mắt đã hiểu ra được trước cả khi dùng tới AI. Trên thực tế, chuyện nguyên nhân lộ ra ngay trong vài tuần đầu sau khi thiết lập truy xuất nguồn gốc tới từng sản phẩm, tức trước khi kịp dựng mô hình, không phải là hiếm.
Tầng thời điểm còn sâu thêm một bậc. Cùng một máy, cùng một lô, nhưng lúc khởi động đầu ca sáng và lúc quá trưa thì biểu đồ nhiệt độ khác nhau. Biến động này bị san phẳng thành giá trị trung bình ở tầng lô, còn ở tầng thời điểm thì vẫn được giữ lại. Khi biết được rằng lỗi “tập trung trong 30 phút khởi động”, biện pháp đối phó sẽ cụ thể hóa thành một chỉ thị công việc rõ ràng là xem lại thời gian gia nhiệt sơ bộ.
Chỗ dễ bị bỏ sót ở đây là hồ sơ của phía hàng đạt. Ở nhiều nhà máy, cách vận hành hiện nay là chỉ ghi chi tiết khi có lỗi, còn hàng đạt thì chỉ đếm số lượng rồi cho đi tiếp. Nhưng phân tích yếu tố là công việc so sánh điều kiện của hàng lỗi với hàng đạt. Không có đối tượng để so sánh thì dù có tìm ra một điều kiện chung của các hàng lỗi, nhà máy vẫn không xác định được điều kiện đó có xuất hiện với mức độ tương tự ở hàng đạt hay không. Nhận định “lúc có lỗi thì nhiệt độ cao” trở nên vô nghĩa ngay khoảnh khắc người ta biết rằng lúc ra hàng đạt nhiệt độ cũng đúng như vậy. Nếu đã gán ID cho từng sản phẩm thì hãy gán cho cả hàng đạt theo đúng cách đó. Giới hạn phạm vi chỉ ở hàng lỗi thì chi phí giảm nhưng phân tích không thành hình.
Nên nắm tầng nào trong ba tầng là do cách lỗi xuất hiện quyết định
Không nhất thiết phải xây dựng cả ba tầng cùng một lúc. Tiêu chí đánh giá nằm ở cách lỗi xuất hiện.
Nếu lỗi xuất hiện theo cụm gom vào từng lô, nhiều khả năng nguyên nhân nằm ở phía lô vật liệu hoặc việc chuyển đổi khuôn và setup, và chỉ với tầng lô nhà máy vẫn khoanh được hướng. Nếu lỗi xuất hiện rải rác bên trong lô, nguyên nhân nằm ở phía từng sản phẩm, số máy và thời điểm, và tầng lô sẽ vĩnh viễn không chạm tới được nguyên nhân. Trước hết hãy dùng hồ sơ lỗi của 3 tháng gần nhất để xác nhận lỗi của công ty bạn đang xuất hiện theo kiểu nào trong hai kiểu đó.
Một trục đánh giá nữa là công đoạn có chạy song song hay không. Cùng một công đoạn có nhiều thiết bị cùng loại, hoặc một bộ khuôn có nhiều cavity. Với cấu hình như vậy, chừng nào chưa xác định được là máy số mấy, cavity nào thì một nửa nguyên nhân đã không nhìn thấy ngay từ đầu. Nhà máy có công đoạn song song thực chất không còn lựa chọn dừng lại ở tầng lô.
Cách đánh số ID cho từng sản phẩm và cách chọn phương tiện đọc mã đã được sắp xếp theo từng điều kiện tại bài Lựa chọn mã vạch cho truy xuất nguồn gốc. Ở đây chỉ cần nhớ một ý, nếu chọn phương thức in ấn mà công đoạn sau không đọc được thì dù đã đánh số, mạch liên kết vẫn đứt ở giữa chừng.
Việc cần xác nhận. Trong hồ sơ lỗi của công ty bạn, có tồn tại đủ ba cột số máy, số cavity và thời điểm hay không. Có tồn tại mà lúc nào cũng để trống thì cũng như không có.
Thiết kế mã lỗi — khi “Khác” vượt quá 30% thì phân tích dừng lại
Dù khóa liên kết đã đủ, nếu thiết kế mã lỗi còn thô thì phân tích vẫn không tiến lên được.
Hãy mở bảng mã lỗi ra và sắp xếp số vụ của một năm gần nhất theo thứ tự giảm dần. Nếu ở nhóm đầu bảng là “Khác”, “Lỗi ngoại quan”, “Lỗi kích thước”, và hơn nữa “Khác” vượt quá 30%, thì dùng dữ liệu đó để phân tích yếu tố sẽ không ra câu trả lời. Lý do rất đơn giản, “Khác” là chỗ gom lại của những thứ không phân loại được nguyên nhân. Nghĩa là thứ người ta muốn biết nhất đã nằm hết trong đó. Mô hình chỉ học được cách dự đoán một nhãn tên là “Khác”, và điều đó hoàn toàn không dẫn tới biện pháp đối phó nào.
Mã lỗi sẽ dễ thiết kế hơn khi được phân tách theo ba trục.
| Trục | Nội dung | Ví dụ |
|---|---|---|
| Hiện tượng | Chuyện gì đã xảy ra | Nứt, mẻ, biến dạng, đổi màu, sai kích thước |
| Vị trí | Xảy ra ở chỗ nào | Phần mặt bích, quanh cổng phun, phần đầu cực, mặt đáy |
| Công đoạn | Được tạo ra ở đâu | Ép phun, gia công cơ khí, lắp ráp, xử lý bề mặt |
Nhân ba trục này lại với nhau thì thoạt nhìn số mã có vẻ tăng lên. Nhưng thứ tăng lên là số dòng của bảng, chứ không phải gánh nặng nhập liệu của hiện trường. Nhân viên kiểm tra chỉ chọn ba menu thả xuống, nhanh hơn nhập tự do. Ngược lại, cách vận hành hiện nay là chọn “Khác” rồi viết thêm bằng tiếng Thái vào ô ghi chú mới thực sự đẩy gánh nặng sang công đoạn phía sau.
Và nhà máy tại Thái Lan còn có thêm một tầng đứt gãy nữa mà nhà máy tại Nhật Bản không có. Đó là vấn đề ba hệ thống ba ngôn ngữ đang gọi cùng một linh kiện bằng những ID khác nhau.
| Hồ sơ | Người lập | Ngôn ngữ | Cách gọi linh kiện |
|---|---|---|---|
| Hồ sơ kiểm tra | Nhân viên kiểm tra | Tiếng Thái (vẫn còn viết tay) | Tên gọi quen dùng tại hiện trường |
| Dữ liệu công đoạn | Thiết bị và PLC | Tiếng Anh (tên tag) | Mã model phía thiết bị |
| Báo cáo sản xuất hằng ngày | Quản lý người Nhật | Tiếng Nhật (Excel) | Số bản vẽ, mã hàng |
Cả ba đều đang chỉ vào cùng một linh kiện, nhưng xét như chuỗi ký tự thì không khớp nhau. Nếu cố liên kết dữ liệu trong trạng thái này, công việc đối chiếu và gộp các tên gọi trùng nhau sẽ phát sinh. Hơn nữa, tiếng Thái viết tay thì cứ để nguyên như vậy sẽ không trở thành đối tượng tìm kiếm được. Không ít nhà máy đang cho người đối chiếu thủ công chỗ này hằng tháng, nhưng giờ công đó thường không được đưa vào báo giá dưới dạng chi phí chuẩn hóa dữ liệu.
Biện pháp đối phó gói gọn ở chỗ chốt một hệ thống mã duy nhất và làm cho cả ba hệ thống đều mang mã đó. Ngôn ngữ hiển thị cứ để nguyên ba thứ tiếng cũng được. Nếu làm theo hình thức màn hình bằng tiếng Thái, lưu trữ bằng mã, gánh nặng nhập liệu của nhân viên kiểm tra không tăng mà việc liên kết ở phía sau vẫn thành hình. Thiết kế tổng thể cho cách nắm giữ hồ sơ chất lượng đã được bàn tại bài Cách chọn hệ thống quản lý dữ liệu chất lượng, nhưng xét về thứ tự thì chốt hệ thống mã trước khi chọn hệ thống phần mềm sẽ ít phải làm lại hơn.
Cũng xin nói thêm về cách tiến hành thực tế khi làm lại hệ thống mã. Không gán lại ngược về quá khứ. Việc gán lại phần dữ liệu cũ vừa không ước lượng được giờ công, vừa không còn ai biết hiện tượng lúc đó ra sao, nên rốt cuộc chỉ tái hiện lại “Khác” dưới một cái tên khác. Mã mới áp dụng từ ngày chuyển đổi, còn trước đó cứ để nguyên mã cũ. Khoảng thời gian làm đối tượng phân tích chỉ cần tính từ sau ngày chuyển đổi là đủ. Ở giai đoạn đầu chuyển đổi, chỉ cần đặt sẵn bên cạnh nhân viên kiểm tra một tờ giấy ghi kèm mã cũ khi họ chọn mã mới, độ dao động trong lựa chọn đã giảm đi khá nhiều.
Thêm một việc nữa, hãy chốt trước xem ai được quyền thêm lựa chọn mã. Nếu hiện trường tự do thêm vào, sau nửa năm danh sách lựa chọn sẽ phình lên và những mã trùng ý nghĩa sẽ nằm cạnh nhau. Ngược lại, nếu chỉ mình bộ phận đảm bảo chất lượng quản lý và việc thêm mã mất nhiều thời gian, thì cứ có hiện tượng mới là người ta lại chạy về “Khác”. Chốt trước nơi tiếp nhận đề nghị thêm mã và một cuộc họp rà soát mỗi tháng một lần sẽ tránh được cả hai thái cực.
Việc cần xác nhận. Sắp xếp số vụ theo từng mã lỗi của một năm gần nhất theo thứ tự giảm dần, rồi xem tổng của “Khác” và “Lỗi ngoại quan” chiếm bao nhiêu phần trong toàn bộ. Và xem nội dung bên trong chúng có đang được viết bằng chữ tự do ở ô ghi chú hay không.
Chi phí của AI cải thiện tỷ lệ thành phẩm — 5 tầng chi phí và số tháng thu hồi
Chi phí sẽ dễ đánh giá hơn khi được chia theo tầng thay vì theo chức năng. Dưới đây là bảng chi tiết giả định cho một nhà máy vốn Nhật tại Thái Lan với một dây chuyền. Đơn vị tiền tệ là THB, tức baht Thái.
| Tầng | Nội dung | Số tiền (THB) |
|---|---|---|
| 1. Thu thập | Lấy dữ liệu từ PLC và máy kiểm tra, đi dây | 1,200,000 |
| 2. Liên kết | Thiết kế ID, chuẩn hóa dữ liệu master, đồng bộ thời gian | 1,800,000 |
| 3. Nền tảng phân tích và mô hình | Lưu trữ, tiền xử lý, phân tích yếu tố | 900,000 |
| 4. Giao diện hiện trường và kết nối biểu mẫu | Hiển thị và phản hồi ngược về vận hành | 600,000 |
| 5. Định nghĩa yêu cầu và quản lý dự án | Quản lý dự án | 700,000 |
| Tổng chi phí ban đầu | 5,200,000 |
Chi phí vận hành mỗi năm dự kiến 780,000. Các khoản chính là bảo trì nền tảng dữ liệu, huấn luyện lại mô hình và cập nhật dữ liệu master.
Điều đập vào mắt ở bảng này là tầng thứ hai, tầng liên kết, với 1,800,000 là khoản lớn nhất. Theo cảm nhận thông thường, chi phí đưa AI vào có vẻ phải xoay quanh việc phát triển mô hình ở tầng thứ ba. Nhưng thực tế tầng thứ ba là 900,000, tức chỉ bằng một nửa tầng thứ hai. Trọng tâm chi phí của AI cải thiện tỷ lệ thành phẩm nằm ở thiết kế ID chứ không nằm ở mô hình. Và trong báo giá, tầng này thường bị gộp vào một dòng với những cái tên mơ hồ như “chuẩn hóa dữ liệu ban đầu” hay “thiết lập master”, nên rất dễ trở thành mục tiêu của việc mặc cả cắt giảm.
Cắt tầng thứ hai thì chuyện gì xảy ra? Nếu chỉ làm trước tầng thứ ba và tầng thứ tư, tổng cộng 1,500,000 sẽ nằm lại đó mà không nối được với kết quả. Nền tảng phân tích vẫn chạy. Màn hình vẫn hiện ra. Nhưng vì không tạo được bảng dữ liệu làm đầu vào cho phân tích yếu tố, thứ hiện ra chỉ là bản tổng hợp kết quả theo từng công đoạn. Việc tổng hợp thì Excel cũng làm được, nên không thể gọi đó là thành quả tương xứng với khoản đầu tư. Cách làm trước riêng tầng thu thập, tức tầng thứ nhất, thì ít bị lãng phí hơn vì dữ liệu vẫn tích lũy được, nhưng riêng thứ tự bỏ qua tầng thứ hai để nhảy sang tầng thứ ba và thứ tư thì nên tránh. Về cảm nhận chi phí của tầng thu thập, bài Chi phí đưa IoT vào nhà máy có bảng chi tiết theo từng cấu hình.
Phía hiệu quả cũng được đặt ở cùng độ chi tiết như vậy.
| Hạng mục | Giá trị |
|---|---|
| Giá trị sản xuất một năm của dây chuyền mục tiêu (THB) | 240,000,000 |
| Tỷ lệ thành phẩm hiện tại | 96.4% |
| Tổn thất do lỗi hiện tại (3.6%) | 8,640,000 |
| Tỷ lệ thành phẩm sau cải thiện | 97.6% |
| Tổn thất do lỗi sau cải thiện | 5,760,000 |
| Mức cắt giảm mỗi năm | 2,880,000 |
| Chi phí vận hành mỗi năm | 780,000 |
| Số tiền ròng mỗi năm sau khi trừ chi phí vận hành | 2,100,000 |
| Thu hồi đơn giản (ban đầu 5,200,000 chia cho 2,100,000) | 29.7 tháng |
Biên độ cải thiện tỷ lệ thành phẩm được đặt ở mức cộng thêm 1.2 điểm. Con số này trông có vẻ dè dặt, nhưng nguyên nhân tìm được qua phân tích yếu tố trong đa số trường hợp tập trung vào một hoặc hai điều kiện, và hiệu quả khi xử lý dứt điểm chỗ đó nằm gọn trong biên độ chừng này. Ngược lại, nếu có đề xuất kiểu “giảm một nửa số lỗi” xuất hiện, bạn nên hỏi lại căn cứ của nó nằm ở điều kiện nào của công đoạn nào.
Trường hợp ngân sách không đủ, cũng nên sắp xếp trước xem tầng nào có thể để lại sau. Khoản 600,000 của tầng thứ tư, giao diện hiện trường và kết nối biểu mẫu, ở lần đầu thường chỉ cần hình thức đơn giản là đủ. Việc trả kết quả phân tích yếu tố về hiện trường, trước mắt dùng tài liệu báo cáo hằng tháng vẫn thành hình. Tầng thứ năm, định nghĩa yêu cầu và quản lý dự án, trông có vẻ cắt được, nhưng cắt đi thì việc điều phối bắc ngang ba hệ thống sẽ không ai đảm nhận, và rốt cuộc tầng thứ hai không tiến lên nổi. Tầng thứ nhất, thu thập, có thể giảm nếu thu hẹp phạm vi. Không mở đối tượng ra toàn bộ công đoạn ngay từ đầu mà giới hạn ở một công đoạn nhiều lỗi, thì phần đi dây và số điểm thu thập cũng giảm theo. Thứ được phép cắt là phạm vi, không phải tầng.
Đọc con số 29.7 tháng thu hồi vốn như thế nào là tùy vào tiêu chuẩn đầu tư thiết bị của từng nơi. Nhà máy lấy điều kiện trong vòng 3 năm thì con số này đi qua được. Trong vòng 2 năm thì không. Trước khi dừng việc cân nhắc tại đây, thứ bạn nên xem lại là tử số chứ không phải mẫu số. Nếu giá trị sản xuất một năm của dây chuyền mục tiêu lớn hơn 240,000,000 thì với cùng chừng đó chi phí, thời gian thu hồi sẽ ngắn lại. AI cải thiện tỷ lệ thành phẩm có mức đầu tư không tỷ lệ thuận nhiều với quy mô sản xuất. Khi mở rộng cơ chế đã dựng cho một dây chuyền sang dây chuyền thứ hai, thứ tăng thêm chỉ là một phần của tầng thu thập, còn các tầng thứ hai, thứ ba và thứ tư gần như dùng lại được. Vì vậy, chọn dây chuyền có giá trị sản xuất lớn nhất làm dây chuyền đầu tiên là lựa chọn hợp lý.

Việc cần xác nhận. Giá trị sản xuất một năm của dây chuyền mục tiêu, và số tiền tổn thất do lỗi hiện tại. Hai con số này lấy từ tài liệu của kế toán và đảm bảo chất lượng là ra trong 30 phút. Nếu số tiền đó không lớn hơn đáng kể so với chi phí vận hành mỗi năm 780,000 thì dây chuyền ấy không phù hợp để làm đối tượng.
Những điều cần xác nhận trước tại nhà máy Thái Lan — giá trị của một điểm tỷ lệ thành phẩm
Nhà máy đang vận hành tại Thái Lan có những căn cứ đánh giá khác với trong nước Nhật Bản.
Ngày 5 tháng 1 năm 2026, JSCCIB, tổ chức chung gồm Phòng Thương mại Thái Lan, Liên đoàn Công nghiệp Thái Lan và Hiệp hội Ngân hàng Thái Lan, đã chỉ ra tình trạng tỷ lệ vận hành thiết bị ở nhiều doanh nghiệp chế tạo đang thấp hơn 60%, cùng với triển vọng xuất khẩu khắc nghiệt. Các bản tin cùng thời điểm cho biết dự báo tăng trưởng GDP năm 2026 ở mức 1.6 đến 2.0%. Khi tỷ lệ vận hành giảm, chi phí cố định vẫn giữ nguyên trong lúc mẫu số nhỏ lại, nên giá thành sản xuất trên mỗi sản phẩm sẽ tăng.
Mặt khác, giữa các ngành cũng có khác biệt. Bài viết ngày 8 tháng 6 năm 2026 của Tân Hoa Xã đưa tin rằng các lĩnh vực như điện và điện tử, điều hòa không khí, thực phẩm và đồ uống, sản phẩm cao su đang được nhu cầu nâng đỡ, trong khi các ngành kiểu cũ lại bị chi phí điện cao, tình trạng thiếu nguyên vật liệu và cạnh tranh từ nước ngoài chèn ép. Công ty bạn đang đứng ở phía nào sẽ quyết định những nước đi có thể thực hiện.
Thứ phát huy tác dụng trong cục diện này là câu hỏi khi không tăng được giá bán thì nguồn lợi nhuận tự thân nào còn lại. Giá bán do thị trường quyết định. Chi phí nguyên vật liệu phụ thuộc vào đàm phán với nhà cung cấp. Chi phí nhân công không hạ được. Đơn giá điện thì tự công ty cũng không điều chỉnh được. Thứ còn lại chỉ là đúng một điểm, giảm được bao nhiêu phần vật liệu và giờ công đã bỏ vào nhưng không thành sản phẩm mà bị vứt đi.
Ở dây chuyền mô hình, phần bị vứt đi ấy là 8,640,000 mỗi năm. Dịch chuyển tỷ lệ thành phẩm thêm 1.2 điểm thì 2,880,000 được giữ lại. Đây là khoản lợi nhuận tạo ra hoàn toàn bên trong công đoạn của chính công ty bạn, không phải nhờ đàm phán tăng giá cũng không nhờ tỷ lệ vận hành hồi phục. Trong cục diện tỷ lệ vận hành thấp, thậm chí còn có mặt dễ thực hiện hơn. Nếu dây chuyền không chạy hết công suất thường xuyên, nhà máy có dư địa để chạy các đợt kiểm chứng với điều kiện thay đổi.
Về mặt thực tiễn mang tính đặc thù Thái Lan, còn một việc cần xác nhận nữa. Đó là trong công ty có người chạm được vào dữ liệu hay không. Để duy trì đều đặn việc trích xuất dữ liệu công đoạn và chuẩn hóa dữ liệu master, cần đặt người phụ trách nằm trong đội ngũ nhân viên bản địa. Nếu tổ chức theo tiền đề để quản lý người Nhật kiêm nhiệm, thì tới lúc thay người sang nhiệm kỳ mới, vận hành sẽ dừng lại. Làm cho hệ thống thao tác được bằng tiếng Thái và bàn giao được bằng tiếng Thái chính là điều kiện để nó còn chạy sau 3 năm. Các công ty khác đang tự vận hành nội bộ tới đâu tại hiện trường thì bài Các ví dụ ứng dụng AI tại hiện trường có nêu, bao gồm cả phần cơ cấu vận hành.
Việc cần xác nhận. Giá trị sản xuất một năm của công ty bạn nhân với tỷ lệ lỗi hiện tại. Số tiền đó có tương xứng với quy mô ngân sách của hoạt động mà nội bộ vẫn gọi là cải thiện tỷ lệ thành phẩm hay không.
Cách tiến hành — dùng 90 ngày chỉ để xác nhận đúng một việc là có liên kết được hay không
Không cần ký ngay hợp đồng xây dựng toàn bộ. Thứ cần xác nhận trong 90 ngày đầu tiên không phải độ chính xác của mô hình, mà là rốt cuộc có liên kết được hay không.
| Giai đoạn | Việc cần làm | Tiêu chí đạt hay không đạt |
|---|---|---|
| 30 ngày đầu | Kiểm kê dữ liệu. Với ba hệ thống là hồ sơ lỗi, dữ liệu công đoạn và kết quả sản xuất, lập danh mục các hạng mục, độ chi tiết, thời gian lưu trữ và cách nắm giữ thời điểm | Danh mục hạng mục của ba hệ thống đã gom được vào một bảng duy nhất hay chưa |
| 30 ngày tiếp theo | Thử nghiệm liên kết. Thu hẹp về một công đoạn và một mã hàng, thử liên kết dữ liệu thật | Hàng lỗi và hàng đạt đã xếp cạnh nhau với các giá trị điều kiện công đoạn khác nhau hay chưa |
| 30 ngày cuối | Phân tích yếu tố cho một chủ đề. Dùng dữ liệu đã liên kết được để khoanh yếu tố cho một hiện tượng lỗi | Hiện trường có công nhận rằng đúng là lỗi xuất hiện khi rơi vào điều kiện đó hay không |
Trong ba giai đoạn, nơi phát lộ nhiều thất bại nhất là giai đoạn thứ hai. Và việc phát lộ ở đó là điều đúng đắn. Biết được rằng không liên kết được chỉ sau 90 ngày là một cuộc kiểm chứng thành công. Ở giai đoạn này, nhà máy xác định được thứ cần bổ sung là đánh số ID cho từng sản phẩm, hay đồng bộ thời gian, hay làm lại mã lỗi, và chỉ phải bỏ chi phí đúng vào chỗ đó. Nếu biết được điều đó sau khi đã ký hợp đồng xây dựng toàn bộ, thì tầng thứ ba và tầng thứ tư vốn đã đặt hàng rồi sẽ treo lơ lửng.
Việc thu hẹp về một chủ đề trong 30 ngày cuối cũng có lý do. Phân tích yếu tố càng mở rộng chủ đề thì kết quả càng khó diễn giải. Hỏi về “nguyên nhân của lỗi nói chung” thì thứ hiện ra là những biến hiển nhiên như mã hàng hay công đoạn. Thu hẹp tới mức “vết nứt xuất hiện ở công đoạn Y của mã hàng X” thì biến hiện ra sẽ chính là các điều kiện. Mục đích của 90 ngày là đưa ra kết quả ở dạng mà hiện trường tự đánh giá được.
Trong giai đoạn này, thứ cần đòi hỏi ở nhà cung cấp không phải phần giải thích về mô hình mà là danh mục các hạng mục đã không liên kết được. Nếu đối tác đưa ra được danh mục ấy một cách cụ thể, thì chặng đường tiếp theo cũng sẽ tiến hành được một cách thực tế.
Về cơ cấu nhân sự cũng nên chốt trước. Cuộc kiểm chứng 90 ngày cần ba người, một người từ đảm bảo chất lượng có thể xuất hồ sơ lỗi, một người từ kỹ thuật sản xuất có thể xuất dữ liệu công đoạn, và một người từ sản xuất có thể khẳng định rằng “đúng là lỗi xuất hiện khi rơi vào điều kiện đó”. Thiếu người thứ ba thì không ai đánh giá được tính hợp lý của kết quả phân tích, và cuối cùng chỉ còn lại bản báo cáo. Ngược lại, nếu tổ chức được cơ cấu mà ba người này cùng ngồi được trong một cuộc họp, thì cuộc kiểm chứng ít phụ thuộc vào năng lực của nhà cung cấp. Phần lớn công việc đều tiến hành được mà không phải dừng dây chuyền, nên thời kỳ tỷ lệ vận hành đang xuống thấp lại càng dễ khởi động.
Việc cần xác nhận. Nếu bản đề xuất chỉ viết mỗi chữ “chuẩn hóa dữ liệu”, hãy yêu cầu nhà cung cấp bóc tách nội dung đó xuống tới mức danh mục hạng mục của ba hệ thống. Đề xuất không bóc tách được sẽ dừng lại vào ngày thứ 90.
Câu hỏi thường gặp
AI cải thiện tỷ lệ thành phẩm là gì?
Đó là cơ chế đối chiếu dữ liệu công đoạn với hồ sơ lỗi để khoanh lại nguyên nhân phát sinh lỗi, hoặc để đọc trước những lỗi sắp xuất hiện. Nó khác mục đích với AI kiểm tra ngoại quan vốn tìm lỗi bằng hình ảnh. Thứ AI kiểm tra ngoại quan dịch chuyển là tỷ lệ lọt lỗi và giờ công kiểm tra, còn thứ AI cải thiện tỷ lệ thành phẩm dịch chuyển là chính tỷ lệ phát sinh lỗi. Điều kiện để nó thành hình nằm ở chỗ hồ sơ lỗi và hồ sơ công đoạn nối được với nhau bằng cùng một khóa.
Chi phí của AI cải thiện tỷ lệ thành phẩm là bao nhiêu?
Với giả định một nhà máy vốn Nhật tại Thái Lan và một dây chuyền, chi phí ban đầu là 5,200,000 THB, chi phí vận hành mỗi năm là 780,000 THB. Chi tiết gồm thu thập 1,200,000, liên kết 1,800,000, nền tảng phân tích và mô hình 900,000, giao diện hiện trường và kết nối biểu mẫu 600,000, định nghĩa yêu cầu và quản lý dự án 700,000. Tầng lớn nhất không phải mô hình mà là liên kết, và cắt chỗ này thì 1,500,000 của nền tảng phân tích cùng giao diện hiện trường sẽ không nối được với kết quả.
Nên đưa AI kiểm tra ngoại quan hay AI cải thiện tỷ lệ thành phẩm vào trước?
Điều đó do chỉ số đang gây khó khăn quyết định. Nếu vấn đề là khiếu nại từ khách hàng và hàng lỗi lọt ra ngoài thì AI kiểm tra ngoại quan đi trước, còn nếu vấn đề là chính việc phát sinh lỗi trong nội bộ thì AI cải thiện tỷ lệ thành phẩm đi trước. Nếu cả hai đều là bài toán, đưa AI kiểm tra ngoại quan vào trước sẽ cho hiệu quả sớm hơn. Tuy nhiên, nếu lưu kết quả đánh giá của AI kiểm tra ngoại quan gắn với ID của từng sản phẩm, thì chính nó trở thành đầu vào cho AI cải thiện tỷ lệ thành phẩm. Xét về thứ tự, hoàn tất việc đánh số ID cho từng sản phẩm ngay tại thời điểm đưa AI kiểm tra ngoại quan vào sẽ ít lãng phí nhất.
Dữ liệu lỗi cần khoảng thời gian và số lượng bao nhiêu?
Độ chi tiết của hồ sơ phát huy tác dụng trước cả khoảng thời gian và số lượng. Nếu chỉ có hồ sơ ở mức lô thì có bao nhiêu năm dữ liệu cũng không ra được yếu tố. Ngược lại, nếu đã đủ tới tầng đơn chiếc và tầng thời điểm, chỉ cần thu hẹp đối tượng về một công đoạn một mã hàng và có đủ khoảng thời gian để nhìn được cả biến động theo mùa là đã khoanh được hướng. Thứ cần xác nhận trước không phải lượng tích lũy, mà là hàng lỗi và hàng đạt có đang mang những giá trị điều kiện công đoạn khác nhau hay không.
Công đoạn vốn đã có tỷ lệ lỗi thấp thì có hiệu quả không?
Hãy đánh giá bằng số tiền. Ở dây chuyền mô hình, tổn thất do lỗi là 8,640,000 mỗi năm và mức cải thiện thêm 1.2 điểm mang lại 2,880,000. Nếu giá trị sản xuất lớn thì dù tỷ lệ lỗi thấp, số tiền vẫn còn lại. Ngược lại, ở dây chuyền có giá trị sản xuất nhỏ thì dù tỷ lệ lỗi cao vẫn có trường hợp không thu hồi nổi chi phí vận hành mỗi năm 780,000. Hãy đặt cạnh nhau số tiền tổn thất do lỗi của dây chuyền đó và chi phí vận hành để so sánh, thay vì so theo phần trăm tỷ lệ lỗi.
Phân tích dữ liệu công đoạn nên làm nội bộ hay thuê ngoài?
Chia theo tầng là cách thực tế. Thiết kế ID, chuẩn hóa dữ liệu master và đồng bộ thời gian đòi hỏi kiến thức về công đoạn của chính công ty, nên dù thuê ngoài thì công ty bạn vẫn phải là chủ thể. Việc xây dựng nền tảng phân tích và cài đặt mô hình thì hợp với thuê ngoài. Việc huấn luyện lại và cập nhật dữ liệu master ở giai đoạn vận hành, nếu không để lại cho nhân viên bản địa thì sẽ không duy trì được. Ngoài ra, câu hỏi liệu có thể thay thế cửa ngõ của phân tích yếu tố bằng AI tạo sinh hay không cần được kiểm chứng riêng, xin mời tham khảo bài AI tạo sinh có dùng được cho phân tích dữ liệu không.
Tổng kết
Thứ phân định thành bại của AI cải thiện tỷ lệ thành phẩm không phải độ chính xác của mô hình, mà là hồ sơ lỗi và hồ sơ công đoạn có nối được với nhau bằng cùng một khóa hay không. Phần lớn khoảng chênh giữa “thu thập khoảng 70%” và “có hiệu quả khoảng 40%” mà Sách trắng ngành chế tạo bản 2026 chỉ ra không nằm ở nhóm chưa thu thập được, mà phát sinh ở nhóm có thu thập nhưng không nối được.
Thứ tự đánh giá thu gọn lại còn ba điều. Thứ nhất, tách bạch AI kiểm tra ngoại quan với AI cải thiện tỷ lệ thành phẩm. Thứ mà loại đầu dịch chuyển là tỷ lệ lọt lỗi chứ không phải tỷ lệ thành phẩm. Thứ hai, nắm khóa liên kết theo ba tầng lô, đơn chiếc và thời điểm, rồi chốt tầng cần thiết theo cách lỗi xuất hiện ở nhà máy mình. Với hồ sơ ở mức lô, hàng lỗi và hàng đạt mang cùng giá trị điều kiện nên nguyên nhân sẽ không lộ ra. Thứ ba, giảm phần “Khác” trong mã lỗi. Độ phân giải của phân tích không thể vượt quá độ phân giải thiết kế của mã lỗi.
Chi phí ban đầu là 5,200,000 THB, chi phí vận hành mỗi năm là 780,000 THB. Tầng lớn nhất là liên kết với 1,800,000, và cắt chỗ này thì 1,500,000 của nền tảng phân tích cùng giao diện hiện trường sẽ treo lơ lửng. Về phía hiệu quả, với dây chuyền có giá trị sản xuất một năm 240,000,000 THB, dịch chuyển tỷ lệ thành phẩm từ 96.4% lên 97.6% sẽ cho mức cắt giảm 2,880,000, số tiền ròng sau khi trừ chi phí vận hành là 2,100,000, và thu hồi đơn giản là 29.7 tháng. Trong cục diện tỷ lệ vận hành xuống dưới 60% và việc tăng giá khó được chấp nhận, khoản 2,880,000 này là một trong số ít nguồn lợi nhuận có thể tạo ra hoàn toàn bên trong công đoạn của chính công ty bạn.
Việc đầu tiên cần làm không phải ký hợp đồng cũng không phải chọn nhà cung cấp. Đó là đặt cạnh nhau file CSV của hồ sơ lỗi và dữ liệu công đoạn rồi xem có cột nào chung hay không.
Việc dữ liệu của công ty bạn có liên kết được hay không đều có thể đánh giá ngay từ giai đoạn trước khi chọn hệ thống. TOMAS TECH đang hỗ trợ các nhà máy vốn Nhật tại Thái Lan sắp xếp xem cần động vào tầng nào, sau khi thực tế kiểm tra đầu ra của máy kiểm tra, PLC và hệ thống quản lý sản xuất hiện có. Ngay cả khi bạn còn ở giai đoạn cân nhắc và chưa quyết định triển khai, chúng tôi vẫn tiếp nhận trao đổi trong lúc cùng nhìn vào dữ liệu sẵn có. Xin liên hệ qua trang Liên hệ.
Nguồn tham khảo
- Sách trắng ngành chế tạo bản 2026 của Nhật Bản, 2026年版ものづくり白書 (Bộ Kinh tế Thương mại và Công nghiệp, Bộ Y tế Lao động và Phúc lợi, Bộ Giáo dục Văn hóa Thể thao Khoa học và Công nghệ, được Nội các thông qua ngày 29 tháng 5 năm 2026) https://www.meti.go.jp/report/whitepaper/mono/2026/pdf/gaiyo.pdf
- Project Design Online, “2026年版ものづくり白書を閣議決定” tức Nội các thông qua Sách trắng ngành chế tạo bản 2026 (tháng 6 năm 2026) https://www.projectdesign.jp/articles/news/874807b9-713f-420d-805c-5cb66072cf47
- The Nation Thailand, “FTI warns of ‘perfect storm’ as 2026 GDP growth seen at 1.6–2.0%” (ngày 5 tháng 1 năm 2026) https://www.nationthailand.com/business/economy/40060791
- Xinhua, “Thai industrial sector sees mixed outlook amid tech growth” (ngày 8 tháng 6 năm 2026) https://english.news.cn/asiapacific/20260608/faa838fea8ad46ef87ac64736d8dc6a9/c.html
- Databricks, “Manufacturing Root Cause Analysis with Causal AI” https://www.databricks.com/blog/manufacturing-root-cause-analysis-causal-ai
- Arch Systems, “From Machine Data Extraction to Manufacturing Root Cause Analysis” https://archsys.io/hub/articles/from-machine-data-extraction-to-manufacturing-root-cause-analysis/