Series Từ số hóa đến AI #24: Có cần làm sạch toàn bộ dữ liệu trước khi triển khai AI không?

I. Trước hết, phân biệt “có dữ liệu” và “dữ liệu dùng được”

Dữ liệu tồn tại trong Excel, ERP, CMMS hoặc database chưa có nghĩa là dùng được cho AI. Một bộ dữ liệu dùng được cần trả lời:

• Đối tượng nào: máy, lệnh, sản phẩm, lô, lỗi hay tài liệu?
• Sự kiện xảy ra khi nào và ở đâu?
• Ai hoặc hệ thống nào ghi nhận?
• Định nghĩa trường dữ liệu có thống nhất không?
• Có đủ bối cảnh để hiểu nguyên nhân và kết quả không?
• Dữ liệu có thể liên kết với nguồn khác bằng mã hoặc thời gian không?
• Người dùng có tin và dùng dữ liệu để quyết định không?

Ví dụ, 10.000 phiếu bảo trì ghi “máy hư - đã sửa” có khối lượng lớn nhưng giá trị phân tích thấp. Một tập nhỏ hơn có triệu chứng, nguyên nhân, hành động, thời gian và phụ tùng có thể hữu ích hơn nhiều.

II. Vì sao không nên làm sạch toàn bộ ngay từ đầu?

Phạm vi không gắn với quyết định

Một số dữ liệu có thể không bao giờ được dùng cho use case đầu tiên. Làm sạch chúng trước không tạo giá trị sớm.

Tiêu chuẩn “sạch” phụ thuộc mục đích

Dữ liệu đủ cho dashboard tuần chưa chắc đủ cho dự báo thời gian thực. Tài liệu đủ để tìm kiếm chưa chắc đủ để AI đưa hướng dẫn kỹ thuật. Không có một mức sạch chung cho mọi bài toán.

Chi phí cơ hội lớn

Đội ngũ có thể dành nhiều tháng sửa dữ liệu cũ trong khi chưa cải thiện được quy trình tạo dữ liệu mới. Nếu nguồn phát sinh vẫn nhập sai, dữ liệu sẽ lại bẩn.

Dễ biến thành dự án IT tách khỏi vận hành

Làm sạch dữ liệu cần chủ sở hữu nghiệp vụ. IT không thể tự quyết nguyên nhân dừng nào đúng, lỗi chất lượng nào tương đương hoặc phiên bản SOP nào còn hiệu lực.

III. Bắt đầu từ use case, không bắt đầu từ kho dữ liệu

Hãy mô tả use case bằng một quyết định cụ thể.

Sau khi xác định dữ liệu tối thiểu, nhà máy mới quyết định làm sạch trường nào, lịch sử bao lâu và mức chất lượng nào chấp nhận được.

IV. Làm sạch theo bốn lớp dữ liệu

Lớp 1: Master data

Gồm thiết bị, dây chuyền, sản phẩm, công đoạn, vật tư, phụ tùng, mã lỗi và nhóm nguyên nhân. Đây là lớp giúp các hệ thống gọi cùng một đối tượng bằng cùng một cách.

Công việc thường gồm:

• Loại mã trùng hoặc lỗi thời.
• Chọn mã chuẩn và bảng đối chiếu.
• Xác định cây phân cấp.
• Gán owner và quy tắc tạo/sửa mã.
• Làm rõ đơn vị tính và trạng thái.

Lớp 2: Dữ liệu giao dịch/vận hành

Gồm dừng máy, work order, PM, sản lượng, lỗi chất lượng, cấp phát phụ tùng. Cần kiểm tra tính đầy đủ, giá trị hợp lệ, timestamp, liên kết và quy tắc đóng bản ghi.

Lớp 3: Dữ liệu máy và cảm biến

Cần kiểm tra tần suất lấy mẫu, đồng bộ thời gian, đơn vị, khoảng giá trị, dữ liệu thiếu, drift cảm biến và mối quan hệ với trạng thái vận hành. Thu thập nhiều không đồng nghĩa với chất lượng cao.

Lớp 4: Tài liệu và tri thức

Cần loại bản trùng, xác định version, trạng thái hiệu lực, metadata, quyền truy cập, chủ sở hữu và độ dễ đọc. Với AI Copilot, tài liệu cũ hoặc mâu thuẫn là rủi ro lớn.

Không phải use case nào cũng cần cả bốn lớp. AI Copilot có thể ưu tiên tài liệu; downtime analytics ưu tiên master và giao dịch; predictive maintenance có thể cần cả dữ liệu máy.

V. Năm chiều chất lượng dữ liệu nên kiểm tra

Đầy đủ

Các trường bắt buộc có được ghi không? Ví dụ bao nhiêu phần trăm sự kiện dừng có nguyên nhân xác nhận?

Hợp lệ/chính xác

Giá trị có nằm trong phạm vi hợp lý và phản ánh thực tế không? Cần kiểm tra mẫu với hiện trường, không chỉ kiểm tra định dạng.

Nhất quán

Cùng một khái niệm có được định nghĩa giống nhau giữa ca, bộ phận và hệ thống không?

Kịp thời

Dữ liệu được ghi khi nào so với sự kiện? Dữ liệu nhập lại sau nhiều giờ có thể phù hợp cho báo cáo nhưng không phù hợp cho cảnh báo.

Có ngữ cảnh và liên kết

Dữ liệu có gắn với máy, lệnh, sản phẩm, ca, tài liệu hoặc người chịu trách nhiệm không? Một con số không có ngữ cảnh khó dùng cho AI.

Có thể chấm 1-5 cho từng chiều và xác định ngưỡng tối thiểu theo use case. Không nên dùng một điểm tổng để che đi một chiều rủi ro nghiêm trọng.

VI. Làm sạch dữ liệu cũ và sửa nguồn phát sinh phải đi cùng nhau

Nếu chỉ sửa dữ liệu lịch sử nhưng form và quy trình hiện tại vẫn cho phép nhập tự do, vấn đề sẽ tái diễn. Mỗi hoạt động làm sạch nên có hai phần:

1. Correction: sửa, gộp, đối chiếu hoặc loại dữ liệu cũ trong phạm vi chọn.
2. Prevention: thay đổi danh mục, validation, workflow, đào tạo và owner để dữ liệu mới tốt hơn.

Ví dụ, thay vì chỉ gộp các biến thể “kẹt liệu”, “jam”, “kẹt phôi” trong dữ liệu cũ, cần tạo danh mục chuẩn, hướng dẫn phân loại và giảm nhập tự do cho dữ liệu mới.

VII. Kế hoạch 30-60 ngày theo use case

Tuần 1: Chốt use case và quyết định

• Ai dùng kết quả?
• Quyết định nào sẽ thay đổi?
• KPI và baseline là gì?
• Phạm vi máy, dây chuyền hoặc tài liệu nào?

Tuần 2: Lập data map

• Dữ liệu nằm ở đâu?
• Nguồn chính thức là gì?
• Ai chịu trách nhiệm?
• Trường nào bắt buộc?
• Mã nào cần đối chiếu?

Tuần 3-4: Profiling và làm sạch mẫu

• Đo tỷ lệ thiếu, trùng, sai định dạng và lệch mã.
• Kiểm tra một tập mẫu với người hiện trường.
• Chuẩn hóa danh mục và quy tắc.
• Chọn dữ liệu lịch sử đủ chất lượng để pilot.

Tuần 5-6: Sửa quy trình tạo dữ liệu

• Rút gọn form.
• Thêm validation và danh mục.
• Xác định người xác nhận.
• Thiết lập log sửa và phản hồi dữ liệu sai.

Tuần 7-8: Chạy pilot và kiểm chứng

• Xây dashboard, phân tích hoặc Copilot mẫu.
• Kiểm tra kết quả với người dùng.
• Ghi lỗi dữ liệu còn lại.
• Quyết định mở rộng, bổ sung hay dừng.

VIII. Ngưỡng “đủ sạch” nên được định nghĩa thế nào?

Không có con số chung. Một cách thực tế là định nghĩa acceptance criteria theo rủi ro.

Ví dụ cho dashboard dừng máy:

• 95% sự kiện có máy và thời gian hợp lệ.
• 90% tổng thời gian dừng có nhóm nguyên nhân xác nhận.
• Mã máy khớp với danh mục chính.
• Sai lệch tổng dừng so với kiểm tra hiện trường nằm trong ngưỡng đã thỏa thuận.
• Dữ liệu được cập nhật trong thời gian phù hợp với cuộc họp ca.

Ví dụ cho AI Copilot:

• 100% tài liệu pilot có owner, version và trạng thái hiệu lực.
• Tài liệu nhạy cảm có quyền truy cập rõ.
• Câu trả lời bắt buộc có nguồn.
• Bộ câu hỏi kiểm thử có tiêu chí đúng/sai và người duyệt.

Các con số trên chỉ là cách minh họa thiết kế tiêu chí, không phải benchmark bắt buộc cho mọi nhà máy.

IX. Khi nào nên tạm dừng use case AI?

Nên tạm dừng hoặc thu hẹp nếu:

• Không xác định được nguồn dữ liệu chính thức.
• Người dùng nghiệp vụ không đồng ý định nghĩa dữ liệu.
• Dữ liệu quan trọng thiếu ở mức không thể kiểm chứng.
• Không có owner sửa dữ liệu và quy trình.
• Rủi ro an toàn/chất lượng cao nhưng AI không có cơ chế kiểm soát.
• Không có cách đo kết quả hoặc so sánh baseline.

Tạm dừng không có nghĩa là từ bỏ AI. Có thể chuyển mục tiêu sang chuẩn hóa dữ liệu hoặc xây dashboard trước.

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

• Làm sạch dữ liệu theo cảm giác thay vì theo use case.
• Chỉ sửa định dạng, không kiểm tra ý nghĩa nghiệp vụ.
• Để IT tự quyết mã và nguyên nhân.
• Cố giữ mọi dữ liệu lịch sử dù không đáng tin.
• Bỏ qua dữ liệu mới phát sinh sau ngày làm sạch.
• Thu thập thêm cảm biến trước khi biết quyết định nào cần dữ liệu đó.
• Dùng AI để “tự làm sạch” mà không có quy tắc và kiểm chứng.
• Không ghi lại giả định, loại trừ và giới hạn của bộ dữ liệu.

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

Dữ liệu chưa chuẩn có làm AI Copilot được không?

Có thể nếu chọn một kho tài liệu nhỏ, xác định phiên bản và quyền rõ. Không nên đưa cả thư mục hỗn hợp vào hệ thống mà không kiểm soát.

Có cần sửa toàn bộ lịch sử nhiều năm không?

Không. Chọn khoảng thời gian phù hợp với use case và chất lượng. Dữ liệu cũ có thể được lưu tra cứu, còn pilot dùng tập gần và đáng tin hơn.

AI có thể tự phát hiện dữ liệu sai không?

AI và quy tắc có thể hỗ trợ phát hiện giá trị bất thường, trùng hoặc thiếu, nhưng không tự biết ý nghĩa nghiệp vụ luôn đúng. Người sở hữu dữ liệu vẫn phải xác nhận.

Nên làm dashboard trước hay làm sạch dữ liệu trước?

Có thể làm song song theo vòng lặp. Dashboard mẫu thường giúp lộ vấn đề dữ liệu; sau đó nhà máy sửa nguồn và cập nhật dashboard. Không cần chờ hoàn hảo mới bắt đầu.