Series Từ số hóa đến AI #3: Dữ liệu hóa là gì và khác gì số hóa trong nhà máy?

I. Số hóa và dữ liệu hóa: khác nhau ở kết quả đầu ra

Hai khái niệm không loại trừ nhau. Một quy trình số hóa tốt nên được thiết kế để tạo ra dữ liệu hóa ngay từ đầu.

II. Ví dụ: cùng là phiếu bảo trì nhưng giá trị dữ liệu rất khác

Phiếu A - đã số hóa nhưng chưa dữ liệu hóa tốt

• Thiết bị: “Máy đóng gói”.
• Hiện tượng: “Máy hư”.
• Xử lý: “Đã sửa xong”.
• Thời gian: không ghi rõ bắt đầu và kết thúc.
• Nguyên nhân: để trống.

Phiếu này xác nhận có một công việc đã xảy ra, nhưng gần như không giúp trả lời máy nào hỏng nhiều, lỗi gì lặp lại, MTTR bao nhiêu, phụ tùng nào thường dùng hoặc PM có hiệu quả không.

Phiếu B - dữ liệu có cấu trúc và ngữ cảnh

• Mã thiết bị: PKG-L02-M03.
• Hiện tượng: motor băng tải quá nhiệt, dòng tăng bất thường.
• Nhóm lỗi: điện/motor.
• Nguyên nhân xác nhận: bạc đạn kẹt do thiếu bôi trơn.
• Hành động: thay bạc đạn, kiểm tra căn chỉnh và bổ sung điểm bôi trơn vào checklist PM.
• Thời gian dừng: 42 phút.
• Phụ tùng: BRG-6205, số lượng 2.
• Liên kết: lệnh sản xuất, ca, người thực hiện và ảnh sau sửa chữa.

Phiếu B có thể dùng cho lịch sử thiết bị, MTTR, phân tích lỗi lặp lại, chi phí phụ tùng, đánh giá PM và kho tri thức troubleshooting.

III. Năm tiêu chí của dữ liệu có thể sử dụng

1. Đúng

Dữ liệu phản ánh tương đối đúng thực tế. Sai mã máy, sai thời gian hoặc chọn sai nguyên nhân sẽ làm dashboard và AI đưa ra kết luận lệch.

2. Đủ

Không phải mọi trường đều phải bắt buộc, nhưng các trường phục vụ quyết định phải được ghi. Một sự kiện dừng máy thiếu nguyên nhân hoặc một lỗi chất lượng thiếu sản phẩm và công đoạn sẽ rất khó phân tích.

3. Nhất quán

Cùng một khái niệm phải được định nghĩa và ghi nhận giống nhau giữa các ca, dây chuyền và bộ phận. “Kẹt liệu”, “jam”, “nghẹt phôi” có thể là cùng một nguyên nhân nhưng bị tách thành ba nhóm nếu không chuẩn hóa.

4. Có ngữ cảnh

Một con số không có ngữ cảnh thường ít giá trị. Sản lượng cần gắn với lệnh, sản phẩm, ca và thời gian; lỗi cần gắn với công đoạn, máy và lô; phiếu bảo trì cần gắn với thiết bị và sự kiện dừng.

5. Kịp thời

Dữ liệu cần được cập nhật đủ sớm để hỗ trợ quyết định. Báo cáo chính xác nhưng đến sau một tuần có thể không giúp trưởng ca xử lý vấn đề trong ca.

Có thể bổ sung tiêu chí về khả năng truy xuất nguồn, quyền truy cập và tính toàn vẹn, đặc biệt với dữ liệu liên quan audit, chất lượng và an toàn.

IV. Ba lớp dữ liệu nhà máy cần phân biệt

Dữ liệu nền - master data

Đây là các danh mục giúp gọi tên mọi thứ thống nhất: thiết bị, vị trí, dây chuyền, sản phẩm, công đoạn, mã lỗi, mã dừng, vật tư, phụ tùng, ca/kíp và người dùng.

Master data không thay đổi liên tục nhưng ảnh hưởng đến gần như mọi báo cáo. Nếu mã nền không thống nhất, kết nối giữa ERP, CMMS, MES và Excel sẽ rất khó.

Dữ liệu giao dịch - operational transactions

Đây là những sự kiện phát sinh hằng ngày: lệnh sản xuất, sản lượng, dừng máy, phiếu bảo trì, kiểm tra chất lượng, xuất nhập kho, checklist, cảnh báo và hành động khắc phục.

Dữ liệu giao dịch cho biết chuyện gì đã xảy ra, ở đâu, khi nào và ai tham gia.

Dữ liệu tri thức - knowledge data

Manual, SOP, checklist, hướng dẫn xử lý sự cố, bài học sau lỗi, lịch sử bảo trì và kinh nghiệm chuyên gia là một lớp dữ liệu khác. Nó không phải lúc nào cũng nằm trong bảng, nhưng rất quan trọng cho AI Copilot và đào tạo nhân sự.

V. Dữ liệu hóa liên quan thế nào đến dashboard và AI?

Một chuỗi giá trị đơn giản có thể được mô tả như sau:

Hoạt động thực tế → ghi nhận có cấu trúc → kiểm tra chất lượng → tổng hợp KPI → dashboard → phân tích/AI → hành động → phản hồi lại dữ liệu.

Dashboard không tự làm dữ liệu tốt lên. Nó chỉ làm cho vấn đề dữ liệu lộ rõ hơn. Nếu số liệu giữa sản xuất và bảo trì khác nhau, dashboard sẽ không tạo ra một sự thật chung chỉ bằng cách đổi biểu đồ.

AI cũng không thể biến dữ liệu sai thành quyết định đúng một cách thần kỳ. AI có thể hỗ trợ làm sạch, phân loại hoặc gợi ý, nhưng nhà máy vẫn cần quy tắc nghiệp vụ và người sở hữu dữ liệu.

VI. Làm sao biết dữ liệu hiện tại có dùng được không?

Chọn một bộ dữ liệu quan trọng trong ba tháng gần nhất và thực hiện bài kiểm tra sau:

1. Tỷ lệ đầy đủ: bao nhiêu bản ghi có đủ trường quan trọng?
2. Tính thống nhất: cùng một nguyên nhân có bao nhiêu cách viết?
3. Khả năng liên kết: có nối được với thiết bị, lệnh sản xuất, sản phẩm hoặc phiếu việc không?
4. Khả năng truy xuất nguồn: có biết ai nhập, nhập khi nào và sửa ra sao không?
5. Khả năng trả lời câu hỏi: dữ liệu có trả lời được câu hỏi quản lý đã đặt không?

Ví dụ, với dữ liệu dừng máy, hãy thử trả lời:

• Top ba máy gây tổng dừng lớn nhất là gì?
• Dừng chủ yếu do thiết bị, vật tư, vận hành hay chất lượng?
• Nhóm nguyên nhân nào tăng ở ca đêm?
• Sự kiện nào đã tạo phiếu bảo trì và kết quả xử lý là gì?

Nếu phải đọc từng dòng ghi chú tự do hoặc hỏi lại người nhập, dữ liệu chưa được cấu trúc đủ.

VII. Không cần dữ liệu hoàn hảo mới bắt đầu

Rất ít nhà máy có dữ liệu hoàn hảo. Cách thực tế là chuẩn hóa theo use case, không làm sạch toàn bộ dữ liệu cùng lúc.

Ví dụ, nếu use case đầu tiên là giảm dừng máy cho dây chuyền A, phạm vi dữ liệu ưu tiên có thể gồm:

• Danh mục máy và cấu trúc dây chuyền.
• Thời gian bắt đầu, kết thúc và thời lượng dừng.
• Nhóm nguyên nhân cấp 1 và cấp 2.
• Ca, lệnh sản xuất, sản phẩm.
• Người xác nhận nguyên nhân.
• Liên kết với phiếu bảo trì nếu có.

Sau khi quy trình này ổn định, nhà máy mới mở rộng sang dây chuyền khác hoặc tăng mức chi tiết.

VIII. Thiết kế dữ liệu ở mức chi tiết nào?

Dữ liệu cần đủ chi tiết để thay đổi quyết định, nhưng không nên khiến người hiện trường quá tải.

Một cách kiểm tra là hỏi với từng trường dữ liệu:

“Nếu có thông tin này, chúng ta sẽ ra quyết định khác đi như thế nào?”

Nếu không có hành động hoặc phân tích nào sử dụng trường đó, chưa chắc cần bắt buộc nhập. Ngược lại, nếu thiếu trường khiến không thể phân biệt nguyên nhân, cần bổ sung hoặc tự động lấy từ hệ thống khác.

Nên ưu tiên danh mục chọn có cấu trúc cho dữ liệu cần tổng hợp, đồng thời giữ ô ghi chú ngắn để lưu ngữ cảnh thực tế. Chỉ dùng nhập tự do cho phần không thể chuẩn hóa hoàn toàn.

IX. Phân công trách nhiệm dữ liệu

Chất lượng dữ liệu không phải việc riêng của IT.

Mỗi nhóm dữ liệu cần có người quyết định định nghĩa, quy tắc, danh mục và cách xử lý sai lệch.

X. Checklist đánh giá nhanh mức dữ liệu hóa

• Có danh mục thiết bị, sản phẩm, lỗi và nguyên nhân dùng chung không?
• Các trường quan trọng được chọn từ danh mục hay nhập tự do?
• Dữ liệu có thời gian, nguồn và người xác nhận rõ không?
• Sự kiện sản xuất, bảo trì và chất lượng có liên kết được không?
• Các bộ phận có dùng cùng định nghĩa KPI không?
• Có đo tỷ lệ thiếu, sai hoặc trễ dữ liệu không?
• Dashboard có được người dùng tin và sử dụng trong họp không?
• Dữ liệu có thể xuất, tích hợp và kiểm tra lịch sử chỉnh sửa không?

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

Dữ liệu trong Excel có được xem là dữ liệu không?

Có. Excel có thể chứa dữ liệu rất giá trị. Vấn đề là kiểm soát phiên bản, cấu trúc, phân quyền, lịch sử chỉnh sửa và khả năng tích hợp. Những file vận hành quan trọng nên được chuẩn hóa và chuyển dần thành nguồn dữ liệu chính thức.

Dữ liệu máy móc có bắt buộc phải lấy tự động không?

Không phải mọi dữ liệu. Trạng thái chạy/dừng, tốc độ hoặc sản lượng có thể nên lấy tự động nếu cần nhanh và chính xác. Nguyên nhân, đánh giá hiện trường và hành động xử lý thường vẫn cần con người xác nhận.

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

Có thể làm trong phạm vi nhỏ, nhưng phải công khai giới hạn và đồng thời cải thiện quy trình ghi nhận. Dashboard không nên che giấu vấn đề chất lượng dữ liệu.

Dữ liệu hóa có phải là thu thập càng nhiều càng tốt không?

Không. Thu thập quá nhiều mà không dùng sẽ tăng chi phí và gánh nặng nhập liệu. Nên bắt đầu từ câu hỏi quản lý và dữ liệu tối thiểu để trả lời câu hỏi đó.