Trước khi triển khai EAM: kiểm tra dữ liệu nào trước?

01

Bắt đầu từ use case, không từ danh sách trường

Hãy chọn hai hoặc ba quyết định cần cải thiện: xác định bad actor, điều chỉnh PM, hoặc lập kế hoạch vật tư cho thiết bị trọng yếu. Với từng quyết định, truy ngược về record, field, người tạo dữ liệu và thời điểm cập nhật. Một field đầy đủ 100% nhưng không được dùng trong quyết định vẫn có thể là ưu tiên thấp.

02

Asset hierarchy và identity

Kiểm tra quan hệ Site → Location → Asset → Component, quy tắc đặt mã, vị trí lắp đặt và vòng đời thay thế. Cùng một bơm có thể xuất hiện trong historian, CMMS và bảng tính với ba tên khác nhau. Cần bảng ánh xạ có chủ sở hữu, quy tắc xử lý đổi tên và hồ sơ ngoại lệ; đừng ghép dữ liệu bằng tên thiết bị tự do.

03

Work Order và failure data

Lấy mẫu Work Order đã đóng: mô tả triệu chứng có đủ hiểu không, asset có đúng không, failure code có mô tả cơ chế hay chỉ ghi “other”, ngày bắt đầu và kết thúc có đáng tin không? Phân biệt yêu cầu công việc, xử lý tạm và khắc phục nguyên nhân. Nếu không, MTBF, repeat failure và chi phí theo asset sẽ gây hiểu nhầm.

04

PM, Job Plan và MRO

Kiểm tra PM có mục tiêu hư hỏng cụ thể, điều kiện kích hoạt, Job Plan, nhân lực, vật tư và tiêu chí hoàn thành. Với MRO, rà đơn vị tính, nhà sản xuất, part number, tương đương kỹ thuật và vật tư trùng mã. Đây là chỗ quy trình và master data phải được sửa cùng nhau.

05

Một pilot đo được

Chọn một asset class và một site. Lập baseline về tỷ lệ Work Order gắn đúng asset, mức độ dùng được của failure code, PM có Job Plan và vật tư trùng. Giao data owner cho từng nhóm, sửa quy tắc nhập liệu, rồi đo lại sau một chu kỳ công việc. Chỉ mở rộng khi đội vận hành thực sự sử dụng dữ liệu đã làm sạch.

06

Chấm chất lượng dữ liệu theo tác động

Tỷ lệ field được điền không đồng nghĩa với dữ liệu dùng được. Nên chấm riêng bốn chiều: completeness (có giá trị), validity (đúng định dạng và danh mục), consistency (khớp giữa các hệ thống) và fitness for use (đủ để đưa ra quyết định). Ví dụ, 95% Work Order có failure code nhưng 80% chọn “Other” sẽ không giúp phân tích bad actor. Cần lấy mẫu theo asset class, tuổi record và nhóm công việc; chỉ số toàn site dễ che khuất khu vực yếu.

Thiết lập ngưỡng chấp nhận theo use case và ghi rõ mẫu số. Với bài toán tối ưu PM, trọng tâm là liên kết Asset–PM–Job Plan–failure mode. Với spare planning, trọng tâm chuyển sang Asset BOM, Item Master, lead time và giao dịch xuất kho. Điểm data readiness nên thể hiện từng use case và từng asset class, kèm danh sách lỗ hổng cần xử lý; một điểm tổng duy nhất thường khó hành động.

07

Thiết kế crosswalk và quy tắc chuyển đổi

Trước migration, lập crosswalk từ mã cũ sang mã đích cho Location, Asset, Item và failure code. Mỗi dòng cần nguồn, mã đích, mức tin cậy, người duyệt và trạng thái ngoại lệ. Quan hệ một-nhiều hoặc nhiều-một phải được quyết định theo nghiệp vụ: hai mã asset có thể là hai vị trí khác nhau, hoặc cùng một thiết bị đã đổi tên. Không nên tự động gộp chỉ vì chuỗi ký tự giống nhau.

Chạy thử trên một tập dữ liệu có đủ trường hợp khó: asset đã tháo, thiết bị thay thế, Work Order mở, vật tư ngừng dùng và PM chưa kích hoạt. Đối chiếu số record, quan hệ cha–con, lịch sử giao dịch và các record bị từ chối. Lưu file mapping có version và rollback plan. UAT phải có planner, maintenance engineer, kho và IT cùng xác nhận những màn hình, báo cáo và giao dịch họ dùng hằng ngày.

08

Giao data ownership vào quy trình vận hành

Một đợt làm sạch dữ liệu sẽ mất tác dụng nếu quy trình tạo record không đổi. Cần quy định ai đề nghị Asset mới, ai duyệt hierarchy, ai quản lý failure taxonomy, ai được sửa Item Master và khi nào thay đổi được đồng bộ sang hệ khác. Form nhập liệu nên kiểm tra các trường bắt buộc theo asset class, nhưng cũng phải cho phép ghi ngoại lệ có lý do để không buộc người dùng nhập giá trị giả.

Sau pilot, theo dõi hàng tháng các lỗi có thể sửa tại nguồn: Work Order thiếu Asset, failure code “Other”, PM không có Job Plan, item thiếu thuộc tính kỹ thuật và mã trùng mới phát sinh. Mỗi KPI cần owner và đường xử lý. Chỉ bàn giao khi có quy tắc quản trị dữ liệu, backlog ngoại lệ và lịch review, không chỉ một bộ dữ liệu sạch tại ngày cutover.

09

Ví dụ minh họa: đánh giá một nhóm bơm

Giả sử pilot có 40 bơm tại một site. Nhóm dự án lấy 12 tháng Work Order, danh sách PM, Asset BOM và dữ liệu historian. Trước hết, họ xác nhận 40 vị trí lắp đặt có Asset ID duy nhất và ánh xạ được tag vận hành. Sau đó lấy mẫu Work Order đã đóng để kiểm tra Asset, triệu chứng, failure code và thời gian dừng máy. Những record ghi “Other” được kỹ sư phân loại lại nếu còn đủ bằng chứng; record thiếu bằng chứng giữ trạng thái chưa xác định. Deliverable không chỉ là bảng tỷ lệ đầy đủ: cần data-gap register, crosswalk ID, quy tắc nhập liệu mới và danh sách PM/Item cần sửa. Go/no-go cho mở rộng dựa trên việc planner và reliability engineer có thể dùng dữ liệu đó để lập một quyết định PM hoặc spare planning có truy vết.