Làm sao để biết dữ liệu nhà máy đủ tin cậy để ra quyết định?

I. Dấu hiệu dữ liệu chưa đáng tin

Cùng một KPI nhưng các bộ phận đưa ra số khác nhau.
Dashboard thường phải “chỉnh tay” trước cuộc họp.
Người dùng quay lại Excel cá nhân để kiểm tra.
Mã máy, sản phẩm hoặc lỗi có nhiều biến thể.
Nhiều trường bắt buộc để trống hoặc chọn “khác”.
Dữ liệu được nhập nhiều giờ/ngày sau sự kiện.
Không biết ai sửa một bản ghi quan trọng.
Khi số bất thường, không drill-down được đến nguồn.
Quy tắc tính KPI chỉ một người hiểu.
Lỗi dữ liệu được sửa nhưng không sửa nguồn phát sinh.

Nếu có nhiều dấu hiệu trên, vấn đề không nên được giải quyết chỉ bằng làm lại dashboard.

II. “Đủ tin cậy” phải gắn với quyết định

Dữ liệu có thể đủ cho báo cáo tháng nhưng chưa đủ cho cảnh báo trong ca. Ví dụ:

Sản lượng cập nhật cuối ca có thể đủ cho báo cáo ngày, nhưng không đủ để phát hiện lệnh trễ giữa ca.
Nguyên nhân dừng ở cấp nhóm có thể đủ cho Pareto ban đầu, nhưng chưa đủ cho RCA kỹ thuật.
Manual được scan có thể đủ để lưu trữ, nhưng chưa đủ cho AI Copilot nếu không rõ version và quyền.

Hãy viết câu: “Dữ liệu này sẽ được dùng để quyết định _____ trong vòng _____.” Câu đó xác định yêu cầu về độ chính xác, chi tiết và độ trễ.

III. Scorecard sáu chiều chất lượng dữ liệu

Chấm 1-5 theo use case.

1. Tính đầy đủ

Các trường cần thiết có được ghi đủ không? Không chỉ đo tỷ lệ ô trống; cần biết trường thiếu có ảnh hưởng quyết định hay không.

Ví dụ: 98% work order có ngày hoàn thành nhưng chỉ 40% có nguyên nhân hỏng. Dữ liệu đủ cho workload nhưng yếu cho reliability.

2. Tính hợp lệ và chính xác

Giá trị có đúng định dạng, nằm trong giới hạn hợp lý và phản ánh thực tế không? Validation có thể bắt số âm hoặc mã sai, nhưng kiểm tra chính xác cần đối chiếu mẫu tại hiện trường hoặc nguồn độc lập.

3. Tính nhất quán

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

4. Tính kịp thời

Khoảng cách từ sự kiện đến lúc dữ liệu sẵn sàng cho người dùng là bao lâu? Có hiển thị timestamp cập nhật và độ trễ không?

5. Ngữ cảnh và khả năng truy nguyên

Dữ liệu có gắn với máy, lệnh, sản phẩm, ca, người tạo và nguồn không? Có drill-down được đến bản ghi gốc và lịch sử chỉnh sửa không?

6. Ownership và kiểm soát

Có người nghiệp vụ chịu trách nhiệm định nghĩa, chất lượng và xử lý issue không? Có quy tắc tạo/sửa, phê duyệt và audit trail không?

Điểm	Diễn giải gợi ý
1	Không rõ nguồn/định nghĩa, không dùng cho quyết định
2	Có dữ liệu nhưng thiếu nhiều, phải kiểm tra thủ công thường xuyên
3	Dùng được trong phạm vi nhỏ, còn giới hạn đã biết
4	Ổn định, có owner, sai lệch thấp và xử lý issue rõ
5	Được kiểm soát liên tục, audit được và tái sử dụng rộng

Không nên lấy trung bình để che một điểm 1 ở chiều critical. Ví dụ dữ liệu an toàn đầy đủ nhưng sai nguồn vẫn không chấp nhận được.

IV. Kiểm tra năm KPI quan trọng nhất

Chọn 5 KPI ban giám đốc/trưởng bộ phận dùng thường xuyên, ví dụ sản lượng, downtime, OEE, lỗi và PM quá hạn. Với mỗi KPI, lập data lineage đơn giản:

Dữ liệu gốc được tạo ở đâu?
Ai hoặc hệ thống nào tạo?
Qua những bước biến đổi nào?
Công thức và loại trừ là gì?
Cập nhật khi nào?
Ai xác nhận?
Nếu sai, sửa ở đâu?
Người xem có drill-down được không?

Sau đó chọn mẫu 10-30 bản ghi để đối chiếu với hiện trường hoặc hồ sơ gốc. Đây thường là cách nhanh nhất để biết dashboard có phản ánh thực tế.

V. Ví dụ kiểm tra KPI downtime

Một KPI downtime đáng tin cần thống nhất:

Planned time là gì?
Dừng dưới bao nhiêu giây/phút có ghi không?
Setup, nghỉ, thiếu kế hoạch được phân loại thế nào?
Event bắt đầu/kết thúc từ PLC hay người nhập?
Ai xác nhận nguyên nhân?
Sự kiện qua ca được xử lý thế nào?
Một sự cố có tạo nhiều work order không?
Chỉnh sửa sau cutoff được ghi lịch sử không?

Nếu những câu này chưa rõ, tranh luận về con số tổng là điều dễ hiểu.

VI. Nguồn dữ liệu rõ và một nguồn chính thức

“Single source of truth” không nhất thiết là một database duy nhất. Nó có nghĩa mỗi loại dữ liệu có nguồn chính được công nhận.

Ví dụ:

ERP là nguồn mã sản phẩm và lệnh.
MES là nguồn sản lượng và trạng thái lệnh.
CMMS là nguồn work order và lịch sử thiết bị.
QMS là nguồn mã lỗi và quyết định chất lượng.
SCADA là nguồn tag và thông số máy.

Dashboard có thể kết hợp, nhưng phải ghi source và xử lý khi dữ liệu xung đột.

VII. Data owner không phải IT

IT chịu trách nhiệm nền tảng, tích hợp, quyền, backup và kỹ thuật. Nhưng bộ phận nghiệp vụ phải sở hữu ý nghĩa:

Sản xuất: sản lượng, ca, dừng, trạng thái.
Bảo trì: asset, work order, failure, PM, phụ tùng.
Chất lượng: defect code, inspection, disposition, CAPA.
Kho: transaction, tồn, lô vật tư.
Kế hoạch: lệnh, target và ưu tiên.

Mỗi nhóm dữ liệu cần owner và data steward/người xử lý hằng ngày nếu quy mô phù hợp.

VIII. Cơ chế sửa sai phải bảo vệ lịch sử

Một dữ liệu sai cần được sửa, nhưng cách sửa phải rõ:

Ai được yêu cầu sửa?
Ai phê duyệt?
Giá trị cũ có được lưu?
Lý do sửa là gì?
Dashboard có cập nhật lại không?
Dữ liệu đã dùng cho báo cáo chính thức được xử lý thế nào?
Có phân tích vì sao lỗi phát sinh không?

Không nên cho phép người dùng sửa trực tiếp mọi dữ liệu sau khi đóng hoặc cutoff. Nhưng quy trình cũng không nên quá phức tạp khiến lỗi tồn tại mãi.

IX. Data quality dashboard nên theo dõi gì?

Tỷ lệ trường bắt buộc đầy đủ.
Tỷ lệ mã không khớp master.
Bản ghi trùng hoặc timestamp bất thường.
Dữ liệu cập nhật trễ so với SLA.
Tỷ lệ chọn “khác”/nhập tự do.
Số data issue mở, quá hạn và theo owner.
Số lần sửa sau cutoff.
Chênh lệch đối chiếu giữa nguồn.
Xu hướng chất lượng theo ca/bộ phận.

Data quality phải được quản lý như một KPI vận hành, không chỉ một lần làm sạch trước go-live.

X. Cách tạo ngưỡng chấp nhận

Ngưỡng nên theo rủi ro và use case. Ví dụ minh họa:

Use case	Tiêu chí chấp nhận gợi ý
Họp daily downtime	≥90% thời gian dừng có nhóm nguyên nhân xác nhận trước cutoff
PM dashboard	100% PM critical có due date, asset, owner và trạng thái
Truy xuất lô	100% lô pilot nối được lệnh, vật tư và kết quả chất lượng bắt buộc
AI Copilot	100% tài liệu pilot có version, owner, quyền và trạng thái hiệu lực

Các tỷ lệ trên là ví dụ thiết kế acceptance criteria, không phải chuẩn chung. Nhà máy cần chọn ngưỡng dựa trên hậu quả sai.

XI. Tạo vòng phản hồi cho người nhập dữ liệu

Dữ liệu tốt hơn khi người dùng thấy kết quả:

Trưởng ca thấy dashboard từ dữ liệu họ xác nhận.
Kỹ thuật viên tìm lại được lịch sử mình ghi.
Chất lượng truy xuất nhanh hơn.
Quản lý phản hồi khi mã/danh mục chưa hợp lý.
Data issue được sửa nhanh, không chỉ nhắc lỗi.

Nếu người dùng chỉ nhận yêu cầu “nhập đủ” mà không thấy lợi ích, chất lượng sẽ giảm.

XII. Dữ liệu đủ tin cậy cho AI khác dashboard thế nào?

AI có thể nhạy hơn với dữ liệu thiếu ngữ cảnh hoặc thiên lệch. Ngoài sáu chiều trên, cần xem:

Dữ liệu có đại diện đủ điều kiện vận hành không?
Nhãn/ground truth được xác nhận thế nào?
Có drift khi máy, sản phẩm hoặc quy trình thay đổi không?
Có giới hạn sử dụng và human review không?
Có bộ kiểm thử và log kết quả không?
Câu trả lời AI có dẫn nguồn không?

Một dashboard tin cậy chưa tự động làm mô hình dự báo đáng tin. Use case AI cần đánh giá riêng.

XIII. Kế hoạch cải thiện trong 30 ngày

Tuần 1

Chọn 5 KPI, chốt owner, source và định nghĩa.

Tuần 2

Đối chiếu mẫu, đo sáu chiều và lập data issue backlog.

Tuần 3

Sửa danh mục, form, validation và workflow cho các lỗi tạo dữ liệu mới.

Tuần 4

Xây data quality dashboard nhỏ, chốt ngưỡng và review trong họp quản lý.

Sau 30 ngày, mục tiêu không phải dữ liệu hoàn hảo mà là biết rõ vấn đề, owner và xu hướng cải thiện.

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

Chỉ kiểm tra số ô trống.
Xem data quality là trách nhiệm IT.
Sửa dữ liệu lịch sử nhưng không sửa form/quy trình.
Dùng một ngưỡng cho mọi use case.
Không hiển thị độ trễ cập nhật.
Dashboard không drill-down đến nguồn.
Sửa số sau họp mà không có audit trail.
Phạt cá nhân từ dữ liệu chưa được xác nhận.
Không đo lại sau hành động.

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

Dữ liệu cần chính xác 100% mới dùng được không?

Không. Mức yêu cầu phụ thuộc quyết định và rủi ro. Cần biết sai lệch, ngưỡng chấp nhận và giới hạn sử dụng.

Nếu các bộ phận có số khác nhau thì chọn số nào?

Trước hết xác định định nghĩa, cutoff và source. Không nên chọn số “có vẻ hợp lý”; cần truy dòng dữ liệu và chốt nguồn chính thức.

Có thể dùng AI để làm data quality không?

AI có thể hỗ trợ phát hiện bất thường, trùng và mô tả không nhất quán. Quy tắc nghiệp vụ và xác nhận của owner vẫn cần thiết.

Bao lâu nên review data quality?

Dữ liệu vận hành quan trọng nên được theo dõi liên tục hoặc hằng tuần; master data và định nghĩa có thể review theo thay đổi và chu kỳ quản trị.

Bài viết được biên tập từ ebook “Từ số hóa đến AI - Sổ tay chuẩn bị cho nhà máy”, Vietsoft, 06/2026.