Series Từ số hóa đến AI #37: Vì sao người dùng không nhập liệu và cách tạo động lực sử dụng hệ thống

I. Vì sao mỗi ca ghi một kiểu?

• Tên gọi hiện trường khác tên trong hệ thống.
• Danh mục nguyên nhân quá chung hoặc quá chi tiết.
• Không phân biệt triệu chứng, nguyên nhân và bộ phận xử lý.
• Form cho phép nhập tự do quá nhiều.
• Đào tạo chỉ hướng dẫn nút bấm, không hướng dẫn phân loại.
• Mỗi trưởng ca tự tạo thói quen riêng.
• Dữ liệu nhập xong không được dùng hoặc phản hồi.
• Người dùng chọn mã nhanh nhất để hoàn thành form.
• Một sự kiện thay đổi nguyên nhân trong quá trình điều tra nhưng hệ thống không lưu hai mức.
• Áp lực sản xuất khiến nhập liệu bị làm sau.

Giải pháp cần xử lý cả thiết kế dữ liệu, UX và quản trị.

II. Phân biệt ba lớp: sự kiện, nguyên nhân sơ bộ và nguyên nhân xác nhận

Ngay khi máy dừng, người vận hành có thể chỉ biết triệu chứng. Không nên ép họ kết luận kỹ thuật.

Có thể thiết kế:

1. Event/triệu chứng: máy dừng, không cấp liệu, alarm X.
2. Nhóm nguyên nhân sơ bộ: thiết bị, vật tư, chất lượng, vận hành, setup, kế hoạch.
3. Nguyên nhân xác nhận: được cập nhật bởi người có trách nhiệm sau điều tra.

Ví dụ:

• Triệu chứng: băng tải không chạy.
• Sơ bộ: thiết bị.
• Xác nhận: sensor lệch vị trí do gá lỏng.

Cách này giữ tốc độ ghi nhận và cải thiện chất lượng phân tích mà không đòi hỏi người vận hành “đoán đúng” ngay.

III. Xây data dictionary dễ hiểu

Mỗi mã quan trọng nên có:

• Tên chuẩn.
• Định nghĩa một câu.
• Khi nào dùng.
• Khi nào không dùng.
• Ví dụ thực tế.
• Ảnh hoặc sơ đồ nếu hữu ích.
• Owner và ngày hiệu lực.
• Mã cha/con.

Ví dụ:

Định nghĩa nên dùng ngôn ngữ người hiện trường, không chỉ thuật ngữ hệ thống.

IV. Danh mục nhiều cấp thay vì hàng trăm mã phẳng

Một taxonomy dừng máy có thể gồm:

• Cấp 1: Planned/Unplanned.
• Cấp 2: Thiết bị, vật tư, chất lượng, vận hành, setup, kế hoạch, nhân lực.
• Cấp 3: Nhóm chi tiết phù hợp.
• Cấp 4: Failure mode xác nhận cho các nhóm cần kỹ thuật.

Người vận hành có thể chọn cấp 2-3; bảo trì bổ sung cấp 4. Không nên bắt mọi người cuộn qua hàng trăm lựa chọn.

V. Thiết kế form tối thiểu cho hiện trường

Với dừng máy, các trường ban đầu có thể là:

• Máy/dây chuyền tự điền theo vị trí hoặc QR.
• Thời gian bắt đầu/kết thúc tự động khi có thể.
• Lệnh/sản phẩm từ kế hoạch.
• Nhóm nguyên nhân sơ bộ.
• Ghi chú/ảnh tùy tình huống.
• Người xác nhận.

Các trường kỹ thuật sâu được bổ sung trong work order. Nguyên tắc là không bắt người dùng nhập lại thông tin hệ thống đã biết.

VI. Đào tạo bằng tình huống, không chỉ bằng slide

Chuẩn bị 10-20 tình huống thường gặp và yêu cầu các ca cùng phân loại. Ví dụ:

1. Hết nguyên liệu tại phễu vì kho chưa cấp.
2. Nguyên liệu có nhưng vít tải kẹt.
3. Máy chạy chậm vì chất lượng yêu cầu kiểm thêm.
4. Dừng đổi sản phẩm theo kế hoạch.
5. Alarm xuất hiện nhưng reset chạy lại, chưa rõ cause.

So sánh kết quả. Nếu tỷ lệ thống nhất thấp, vấn đề nằm ở taxonomy hoặc hướng dẫn, không nên chỉ trách người dùng.

VII. Tổ chức calibration định kỳ

Trong 4-8 tuần đầu:

• Mỗi tuần lấy 10-20 event từ các ca.
• Cùng trưởng ca/bảo trì/chất lượng review.
• Xác định mã nào gây nhầm.
• Cập nhật định nghĩa, ví dụ và decision tree.
• Phản hồi lại cho người dùng.
• Theo dõi tỷ lệ dùng “khác” và sửa sau xác nhận.

Sau khi ổn định, có thể chuyển sang review tháng hoặc theo issue.

VIII. Ví dụ một event được ghi ba cách

Sự kiện thật: Dây chuyền dừng 18 phút vì sensor không nhận sản phẩm sau khi thay format.

• Ca 1 ghi: “lỗi điện”.
• Ca 2 ghi: “setup”.
• Ca 3 ghi: “kẹt máy”.

Sau review, nhà máy thống nhất:

• Event category ban đầu: Setup/Changeover issue nếu xảy ra trong cửa sổ đổi format.
• Failure mode xác nhận: Sensor position misalignment.
• Action: bổ sung điểm kiểm sensor vào checklist changeover.

Một event có thể có cả context “setup” và technical cause “sensor lệch”. Hệ thống nên cho lưu hai chiều thay vì buộc chọn một mã duy nhất.

IX. Phân vai xác nhận dữ liệu

• Người vận hành: ghi event và bối cảnh ban đầu.
• Trưởng ca: xác nhận thời gian, lệnh và nhóm nguyên nhân.
• Bảo trì: xác nhận failure mode/hành động kỹ thuật.
• Chất lượng: xác nhận lỗi/hold/disposition.
• Data owner: quản lý danh mục và quy tắc.
• IT: cấu hình validation, quyền và audit trail.

Không nên để một người sửa mọi dữ liệu cuối tuần để “làm sạch báo cáo”; dữ liệu phải được xác nhận gần thời điểm sự kiện.

X. Theo dõi chất lượng dữ liệu theo ca mà không tạo tâm lý bị phạt

Có thể theo dõi:

• Tỷ lệ event có nguyên nhân sơ bộ đúng hạn.
• Tỷ lệ được xác nhận.
• Tỷ lệ chọn “khác”.
• Số sửa sau cutoff.
• Tỷ lệ thiếu trường bắt buộc.
• Mức đồng thuận khi calibration.

Trong giai đoạn đầu, dùng số liệu để cải thiện form, định nghĩa và đào tạo. Nếu dùng ngay để xếp hạng/phạt cá nhân, người dùng có thể che giấu hoặc chọn mã “an toàn”.

XI. Giảm nhập tự do nhưng không xóa hoàn toàn ghi chú

Danh mục chuẩn phục vụ phân tích. Ghi chú phục vụ ngữ cảnh. Nên kết hợp:

• Trường mã bắt buộc.
• Ghi chú ngắn tùy chọn hoặc bắt buộc cho nhóm “khác”.
• Ảnh/voice note nếu môi trường phù hợp.
• AI hỗ trợ gợi ý mã từ mô tả, nhưng người dùng xác nhận.
• Review mô tả để bổ sung taxonomy khi cần.

Không nên phân tích chính chỉ dựa trên text tự do, nhưng text vẫn hữu ích cho điều tra.

XII. Quản lý thay đổi danh mục

Khi thêm/sửa mã:

• Có request và lý do.
• Owner duyệt.
• Kiểm tra trùng nghĩa.
• Xác định ngày hiệu lực.
• Cập nhật mapping dữ liệu cũ nếu cần.
• Thông báo và đào tạo ngắn.
• Giữ version/audit trail.
• Không xóa mã đã dùng; chuyển inactive.

Danh mục không nên bị đóng cứng, nhưng cũng không để mỗi ca tự tạo.

XIII. Kế hoạch 30 ngày

Tuần 1

Lấy 100 event gần nhất, phân tích biến thể tên và tỷ lệ “khác”.

Tuần 2

Workshop liên ca để thống nhất taxonomy 2-3 cấp và data dictionary.

Tuần 3

Rút gọn form, thêm validation, QR/mặc định và phân vai xác nhận.

Tuần 4

Chạy calibration, đo mức thống nhất, sửa mã gây nhầm và công bố version 1.0.

Tiếp tục review hằng tuần trong hai tháng đầu.

XIV. KPI cần theo dõi

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

• Danh mục do một phòng tự xây, không có hiện trường tham gia.
• Hàng trăm mã phẳng.
• Ép người vận hành chọn nguyên nhân gốc.
• Chỉ đào tạo một lần.
• Không review “khác” và mô tả tự do.
• Form yêu cầu nhập lại lệnh, máy và thời gian.
• So sánh/phạt ca khi định nghĩa chưa ổn.
• Sửa dữ liệu cuối tháng mà không phản hồi.
• Xóa mã cũ làm mất lịch sử.

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

Có nên dùng một danh mục cho toàn nhà máy?

Nên có cấp chung để tổng hợp, nhưng cấp chi tiết có thể theo dây chuyền/công nghệ. Cần mapping và governance thống nhất.

Người vận hành không biết nguyên nhân thì chọn gì?

Cho phép ghi triệu chứng/nhóm sơ bộ và trạng thái “chờ xác nhận”. Người có chuyên môn cập nhật cause sau.

AI có thể tự phân loại mô tả không?

Có thể gợi ý khi có dữ liệu nhãn tốt. Người dùng nên xác nhận, và hệ thống cần theo dõi độ đúng theo từng mã.

Bao lâu nên cập nhật taxonomy?

Review thường xuyên trong pilot, sau đó theo tháng/quý hoặc khi có process/product mới. Thay đổi phải có version và thông báo.