OEE và TPM phối hợp: chỉ số, phương pháp cải thiện và phần mềm phân công thế nào

Trước hết phân rõ ba khái niệm, tránh thay thế lẫn nhau

OEE qua hệ số thời gian vận hành, hệ số hiệu suất và tỷ lệ sản phẩm đạt mô tả tổn thất hiệu quả thiết bị, trả lời 'tổn thất ở đâu, chiếm bao nhiêu thời gian hay sản lượng'. TPM qua người vận hành, bảo trì, công nghệ và quản lý cùng tham gia, dựng cơ chế phòng ngừa, cải thiện và trưởng thành năng lực, trả lời 'ai dùng phương pháp gì giảm tổn thất và phòng tái diễn'.

Phần mềm có thể nối trạng thái thiết bị, andon, điểm kiểm, sửa chữa và bản ghi phân tích, nhưng nó vừa không phải công thức OEE, vừa không phải hệ TPM. Thiếu trách nhiệm, chuẩn và nhịp rà soát, giao diện đầy đủ đến đâu cũng chỉ là trình bày; thiếu dữ liệu sự kiện đáng tin, rà soát TPM lại dễ dựa vào ấn tượng.

Ánh xạ nhánh tổn thất OEE sang hoạt động TPM

Ánh xạ nên xuất phát từ cơ chế tổn thất, chứ không phải chia máy móc từng tổn thất cho một trụ cột nào. Dừng máy do lỗi có thể liên quan bảo trì kế hoạch, cũng có thể bắt nguồn từ thiếu lau dọn điểm kiểm, thay đổi điều kiện vận hành hay thiết kế yếu; dừng ngắn và giảm tốc thường cần người vận hành cùng thiết bị, công nghệ quan sát chung.

Tổn thất chất lượng cũng không thể chỉ giao phòng chất lượng. Độ chính xác thiết bị, trạng thái đồ gá, điều kiện khởi động và tiêu chuẩn vận hành đều có thể ảnh hưởng khuyết tật khởi động và quá trình. Cây tổn thất OEE cung cấp danh sách vấn đề chung, hoạt động TPM tổ chức các vai trò cùng giải quyết, phần mềm thì ghi lại vấn đề có tái diễn không, đối sách có thực thi không.

Dựng vòng khép kín từ sự kiện bất thường đến hành động bảo trì

Một chuỗi sự kiện hành động được thường gồm bản ghi tự động thiết bị, andon hay cuộc gọi thủ công, phản hồi và có mặt, phục hồi tạm, phân tích nguyên nhân, thực thi đối sách và kiểm chứng tái diễn. Thời gian dừng, thời gian sửa và thời gian chờ nên tách hợp lý, nếu không không phán đoán được trọng điểm cải thiện nằm ở độ tin cậy thiết bị hay chuỗi phản hồi.

Andon phụ trách đưa bất thường kịp vào quy trình trách nhiệm, không đồng nghĩa lệnh sửa chữa. Có cần lệnh sửa hay không, ai đóng, lúc nào chuyển cấp và chờ phụ tùng xử lý thế nào, đều nên định nghĩa trong dự án. Giao tiếp phần mềm có thể cấu hình theo hệ bảo trì sẵn có, không nên mặc định kèm sản phẩm TPM độc lập hoàn thiện hay toàn vòng đời thiết bị.

• Phát hiện: giữ tín hiệu thiết bị gốc, thời gian phát sinh và bối cảnh sản phẩm hay chế độ làm việc.
• Phản hồi: ghi cuộc gọi, nhận việc, có mặt, chuyển cấp và phối hợp cần thiết.
• Phục hồi: phân biệt đưa về chế độ tạm, sửa chữa chính thức và xác nhận phục hồi sản xuất.
• Phân tích: dùng dạng lỗi và chứng cứ hiện trường tìm cơ chế, không chỉ điền 'đã xử lý'.
• Phòng ngừa: chuyển đối sách thành điểm kiểm, bảo dưỡng, phụ tùng, chuẩn hay nhiệm vụ cải tạo và kiểm lại tái diễn.

Dữ liệu điểm kiểm, bảo dưỡng và sửa chữa cần nối thế nào

Sổ cái thiết bị cung cấp khóa chính đối tượng, kế hoạch điểm kiểm bảo dưỡng định nghĩa việc phải làm, bản ghi thực thi nói rõ tình hình hoàn thành thực tế, sự kiện sửa chữa lỗi giải thích lịch sử bất thường. Nếu sự kiện OEE không liên kết được với khóa chính thiết bị và trục thời gian, rất khó phán đoán tổn thất có liên quan sót kiểm, quá hạn hay sửa trùng.

Nối dữ liệu không nghĩa mọi chức năng phải dựng trong cùng hệ thống. Nền tảng bảo trì sẵn có có thể tiếp tục làm hệ chính, nền OEE hay andon qua giao tiếp cung cấp sự kiện; nếu dùng vòng lệnh sửa định chế, nên làm rõ ranh giới với hệ thống sẵn có. Mô hình hóa vòng đời thiết bị và lĩnh vực TPM của ORPAON đánh giá mở rộng theo tình huống, không diễn đạt thành sản phẩm TPM độc lập hoàn thiện.

Một lộ trình phối hợp triển khai chạm đất được

Khuyến nghị bắt đầu từ một loại thiết bị và một tổn thất chính, thay vì đồng loạt triển khai trọn bộ mô-đun bảo trì. Trước thống nhất khóa chính thiết bị và chuẩn sự kiện, rồi chọn lỗi lặp hay dừng ngắn triển khai hoạt động TPM, cuối cùng cố hóa chuẩn điểm kiểm, bảo dưỡng hay cải thiện hình thành vào quy trình hằng ngày.

Hiệu quả phối hợp không thể chỉ phán bằng biến động đơn điểm của OEE. Nên đồng thời quan sát tái diễn lỗi, quá trình phản hồi, chất lượng điểm kiểm và biến động khuyết tật, và cố định sản phẩm cùng ranh giới kế hoạch. Nếu dữ liệu chưa đủ, nên ghi rõ 'chưa kiểm chứng', thay vì ghi quan hệ tương quan thành nhân quả hay cam kết lợi ích.

• Bước một: đối chiếu công thức OEE, thời gian kế hoạch và trạng thái thiết bị, hình thành đường cơ sở tổn thất đáng tin.
• Bước hai: chọn tổn thất lặp, tổ chức rà soát liên hợp vận hành, thiết bị, công nghệ và chất lượng.
• Bước ba: theo thiết bị và sự kiện liên kết bản ghi bất thường, phản hồi, sửa chữa và cải thiện.
• Bước bốn: chuyển đối sách thành bảo trì tự chủ, bảo trì kế hoạch hay thay đổi tác nghiệp chuẩn.
• Bước năm: theo cửa sổ cố định kiểm chứng tái diễn và tổn thất OEE, chưa cải thiện thì trở về phân tích cơ chế.

Ba phản mẫu thường gặp và cách sửa

Phản mẫu thứ nhất là dùng OEE đánh giá phòng bảo trì, dẫn tới báo ít dừng máy hay đóng sự kiện nhanh nhất có thể; thứ hai là lấy tỷ lệ hoàn thành điểm kiểm quét mã làm thành quả TPM, bỏ qua bất thường có thực sự được phát hiện và giải quyết; thứ ba là trước mua phần mềm lớn toàn diện, rồi mới tìm quy trình quản lý có thể nhét vào.

Cách sửa là để chỉ số phục vụ rà soát vấn đề, để chuẩn bảo trì do sự kiện hiện trường dẫn dắt, để ranh giới phần mềm theo hệ thống sẵn có và thiết kế trách nhiệm. OEE, TPM và phần mềm giữ vai trò rõ ràng riêng, phối hợp mới không thoái hóa thành trò chơi con số.

• Không lấy rút ngắn thời gian ghi chép thay rút ngắn dừng máy thật.
• Không lấy số lượng nộp điểm kiểm thay tính hiệu quả điểm kiểm và đóng bất thường.
• Không gọi bảng điều khiển andon, bảng OEE hay lệnh sửa định chế là hệ TPM trọn vẹn.
• Không đặt trước sản phẩm APS, WMS, QMS hay TPM độc lập tự giao theo dự án.