Tích hợp ứng dụng kiểm tra di động với MES

Kiểm tra di động khác gì so với phiếu kiểm tra giấy

Nhiều nhà máy nói rằng mình “có kiểm tra”: một tờ phiếu kiểm tra treo trên tường, nhân viên tích theo ca, cuối tháng thu lại lưu trữ.

Chi phí của cách làm này thường không lộ ra. Nó lộ ra ở ba thời điểm: khi khách hàng đến đánh giá nhà máy và yêu cầu hồ sơ, khi thiết bị hỏng cần truy lại trạng thái lúc đó, và khi cơ quan quản lý yêu cầu chứng minh một lần kiểm tra cụ thể đã thực sự được thực hiện. Cả ba thời điểm đều có chung một điểm: thời gian gấp, và không ai muốn lật cả năm giấy tờ.

Ứng dụng kiểm tra di động khác ở ba điểm:

• Nhiệm vụ do hệ thống đẩy xuống, không phải tổ trưởng thông báo miệng: ai, khi nào, kiểm tra thiết bị nào, kiểm tra mục nào đã được ghi lại trước khi ca bắt đầu
• Mục kiểm tra là trường dữ liệu có cấu trúc, không phải dấu tích: mục số liệu nhập thẳng giá trị đo, vượt ngưỡng sẽ cảnh báo ngay tại chỗ, ảnh và mốc thời gian được lưu cùng
• Bất thường là điểm bắt đầu của một quy trình, không phải điểm kết thúc: phát hiện bất thường là sinh phiếu công việc hoặc cảnh báo ngay, không chờ tổng hợp cuối tháng

Một tiêu chí thực tế để đánh giá: chọn ngẫu nhiên một nhân viên kiểm tra. Nếu hệ thống hiện được toàn bộ thời điểm kiểm tra và mọi giá trị đo của người đó trong tháng trước, quy trình kiểm tra di động đã thực sự vận hành.

Ứng dụng kiểm tra di động thường bao gồm những nhóm chức năng nào

Thiết bị di động không phải là một trang web thu nhỏ. Nó đảm nhận trọn vẹn các thao tác công việc của nhân viên tuyến đầu.

Các chức năng thường chia thành bốn nhóm dưới đây, dự án chọn lọc theo thực tế hiện trường:

Không nhất thiết phải triển khai cả bốn nhóm cùng lúc, nhưng kiểm tra và xử lý bất thường nên lên cùng đợt. Chỉ kiểm tra mà không xử lý thì dữ liệu nằm lại trong hệ thống và không ai theo đuổi.

Cơ chế đồng bộ và khả năng dùng ngoại tuyến: giữ mạch dữ liệu không đứt ở nơi sóng yếu

Thực tế nhà máy là: góc xưởng, tầng hầm, phòng điện đều yếu sóng. Nếu ứng dụng buộc phải có kết nối mới dùng được, nhân viên đến đó là không làm được việc.

Cách làm phổ biến là “ưu tiên trực tuyến, dự phòng ngoại tuyến”:

• Nhiệm vụ kiểm tra và hồ sơ thiết bị được tải trước về thiết bị, không có mạng vẫn mở được
• Dữ liệu nhập được ghi vào cơ sở dữ liệu cục bộ trước, giao diện hiển thị rõ số bản ghi chờ đồng bộ
• Khi có kết nối trở lại sẽ tự động gửi bù, bản ghi gửi bù mang mốc thời gian gốc chứ không phải thời điểm tải lên
• Gửi thất bại có cơ chế thử lại và kích hoạt thủ công, không phụ thuộc vào việc một người nhớ bấm nút

Mốc thời gian là điểm dễ bị bỏ qua. Nếu ghi thời điểm tải lên, toàn bộ dữ liệu trong thời gian mất mạng sẽ dồn lại một chỗ trên trục thời gian, khiến việc so sánh xu hướng hay truy lại sự kiện sau này đọc sai trình tự.

Ba phương án tích hợp với MES và cách chọn

Trong thực tế, kết nối giữa ứng dụng kiểm tra di động và MES chia thành ba hướng:

• Hướng đẩy nhiệm vụ: MES sinh nhiệm vụ kiểm tra từ kế hoạch bảo dưỡng và đẩy xuống thiết bị di động. Đây là bước then chốt để kiểm tra thực sự nằm trong tầm kiểm soát
• Hướng trả dữ liệu: bản ghi kiểm tra, phiếu công việc bất thường, kết quả xử lý được ghi ngược về MES, tạo hồ sơ đầy đủ cho cả thiết bị và con người
• Hướng dữ liệu gốc: sổ thiết bị, danh sách điểm kiểm tra, nhân sự và tài khoản quyền được giữ cùng nguồn với MES, tránh hai hệ mã thiết bị song song

Đi theo đường kỹ thuật nào phụ thuộc vào điều kiện giao tiếp hai bên. Các lựa chọn thường gặp là kết nối trực tiếp qua REST, trao đổi qua cơ sở dữ liệu trung gian, hoặc truyền bất đồng bộ qua gateway và kênh tin nhắn. Không có lựa chọn nào vượt trội tuyệt đối: dữ liệu trả về cần tính thời gian thực phù hợp kết nối trực tiếp, tình huống vượt mạng hoặc vượt miền bảo mật phù hợp kênh tin nhắn, còn đồng bộ dữ liệu gốc thường chỉ cần theo ngày hoặc theo ca.

Chọn thiết bị đầu cuối: điện thoại Android, máy cầm tay hay máy tính bảng

Phần mềm di động có đi vào thực tế được hay không phụ thuộc một nửa vào việc chọn đúng thiết bị.

Ba dạng phổ biến có đánh đổi như sau:

Thứ tự chọn nên là: xác định thao tác chính trước (quét nhiều hay nhập nhiều), sau đó chọn dạng thiết bị, cuối cùng mới đến hãng và model. Làm ngược lại, mua thiết bị trước rồi tìm tình huống sau, là lãng phí phổ biến nhất ở loại dự án này.

Tài khoản, quyền và nhật ký kiểm toán

Thiết bị di động mang hệ thống ra tận xưởng, nên thiết kế quyền không thể sao chép cách làm ở văn phòng.

Thường cần chốt bốn điều:

• Gắn tài khoản với nhân sự: tài khoản của thực tập sinh, lao động thời vụ, nhân sự thuê ngoài được cấp và thu hồi thế nào
• Phân cấp vai trò: nhân viên kiểm tra chỉ được nhập, tổ trưởng được xác nhận, chỉ quản lý thiết bị mới được đóng bất thường
• Lưu vết sửa đổi: sau khi nhập có được sửa không, sửa có để lại dấu vết không, ai có quyền sửa
• Thông tin thời gian và vị trí: có ghi thời điểm và vị trí thao tác không, và phạm vi ghi phải được thông báo cho nhân viên từ giai đoạn đầu dự án

Hai điều sau đặc biệt quan trọng ở ngành có yêu cầu tuân thủ cao như dược phẩm và thực phẩm. Nên xác nhận với bộ phận chất lượng ngay khi thiết kế giải pháp thay vì bổ sung sau khi go-live.

Go-live và nghiệm thu: đánh giá ứng dụng có thực sự dùng được

Tranh cãi ở dự án kiểm tra hiếm khi nằm ở việc thiếu chức năng. Nó thường nằm ở việc sau go-live hiện trường có còn dùng hay không.

Nghiệm thu nên tiến hành theo các bước:

• Đo đẩy nhiệm vụ: sinh một nhiệm vụ kiểm tra từ MES và xác nhận nó hiện trên thiết bị di động trong vài giây
• Đo tình huống ngoại tuyến: hoàn thành một vòng kiểm tra ở khu vực không có sóng, sau đó đối chiếu bản ghi gửi bù và mốc thời gian gốc
• Đo đóng bất thường: báo cáo một bất thường tại hiện trường và chạy trọn quy trình phân công, xử lý, xác nhận, kiểm tra bản ghi phía MES đầy đủ
• Đo độ chính xác quét mã: lấy mẫu đọc mã vạch trong điều kiện ánh sáng và dầu mỡ thực tế, xác nhận không phải nhắm lại nhiều lần
• Đo quyền: dùng tài khoản ở các vai trò khác nhau để kiểm tra phạm vi thao tác và xác nhận thao tác vượt quyền bị chặn
• Xác nhận mức độ sẵn sàng: cho chạy thử một ca thực tế, thu thập ý kiến nhân viên kiểm tra rồi mới chốt mục kiểm tra cuối cùng

Bước cuối thường bị bỏ qua nhưng tốn kém nhất. Mục kiểm tra quá chi tiết sẽ khiến tuyến đầu tìm cách bỏ qua, còn quá thô thì khi đánh giá lại không có bằng chứng. Chạy thử một vòng rồi mới chốt hiệu quả hơn nhiều so với tranh luận trong phòng họp.

Ranh giới triển khai: chốt phạm vi thí điểm và cách nhân rộng

Rủi ro khi triển khai ứng dụng kiểm tra tập trung ở hai chỗ: điều kiện hiện trường về thiết bị và mạng, cùng quyền sở hữu giao tiếp với các hệ thống khác. Ghi rõ ranh giới sẽ tiết kiệm rất nhiều giải thích về sau.

Cách làm ổn định là thí điểm ở một xưởng hoặc một chuyền, xác lập vững ba mạch: đẩy nhiệm vụ, gửi bù ngoại tuyến và đóng bất thường, rồi nhân rộng sang các khu vực khác. Chi phí nhân rộng chủ yếu ở việc cấp thiết bị và mở tài khoản; về phần mềm thường chỉ cần điều chỉnh mục kiểm tra và cấu hình điểm kiểm tra.

Trạng thái triển khai thường thể hiện theo ba mức: đã triển khai (đang vận hành tại hiện trường), có thể triển khai (giải pháp và kinh nghiệm đã chín, khởi động ngay theo điều kiện hiện trường), và thí điểm theo yêu cầu (kiểm chứng theo điều kiện cụ thể). Khi liên quan đến giao tiếp với MES, ERP hay hệ thống kho hiện hữu, nên đưa định nghĩa trường dữ liệu và phân chia trách nhiệm vào cùng một vòng xác nhận phạm vi — trường giao tiếp một khi đã chốt thì chi phí thay đổi về sau cao hơn hẳn một vòng trao đổi thêm từ đầu.