Trả lời nhanh: Muốn giảm dừng máy, hãy bắt đầu bằng việc ghi nhận nhất quán máy nào dừng, dừng khi nào, trong bao lâu, vì nhóm nguyên nhân nào, ai xác nhận và hành động gì đã được thực hiện. Sau đó dùng Pareto và dashboard để tập trung vào một vài thiết bị hoặc nguyên nhân gây tổn thất lớn nhất. AI chỉ nên bổ sung khi dữ liệu đủ tốt và câu hỏi phân tích đã rõ.
Dừng máy là một trong những tổn thất dễ thấy nhất nhưng lại thường được ghi nhận kém nhất. Có nhà máy chỉ có tổng số phút dừng cuối ca. Có nơi mỗi ca mô tả nguyên nhân theo cách riêng. Có nơi sự kiện dừng và phiếu bảo trì không liên kết, nên sản xuất và bảo trì mang hai bộ số liệu khác nhau vào cuộc họp.
Giảm downtime không bắt đầu từ một mô hình dự báo phức tạp. Nó bắt đầu từ một định nghĩa thống nhất và dữ liệu sự kiện đủ tin cậy.
I. Vì sao dừng máy khó phân tích?
Không thống nhất thế nào là “dừng”
Một máy chạy chậm có được tính là dừng không? Chờ vật tư, chờ QC, đổi sản phẩm, vệ sinh và mất điện có cùng nhóm không? Dừng dưới hai phút có được ghi? Nếu mỗi ca áp dụng khác nhau, số liệu không thể so sánh.
Chỉ ghi tổng thời gian, không ghi từng sự kiện
Tổng 120 phút dừng không cho biết đó là một sự cố lớn hay 40 lần dừng ngắn. Hai tình huống cần hành động rất khác nhau.
Nguyên nhân được ghi theo cảm nhận ban đầu
Người vận hành có thể chọn “máy hỏng”, nhưng sau kiểm tra nguyên nhân thật là vật tư kẹt hoặc thao tác setup. Cần phân biệt nguyên nhân ban đầu và nguyên nhân đã xác nhận.
Dữ liệu nằm ở nhiều nơi
SCADA có trạng thái chạy/dừng, sản xuất có file dừng, bảo trì có phiếu việc, chất lượng có biên bản lỗi. Nếu không có mã máy và thời gian chung, khó ghép thành một bức tranh.
Chỉ tập trung vào sự cố lớn, bỏ qua dừng ngắn
Nhiều lần dừng 1-3 phút có thể gây tổn thất tổng lớn và kéo Performance xuống, nhưng dễ bị bỏ qua vì không tạo phiếu bảo trì.
II. Dữ liệu tối thiểu của một sự kiện dừng máy
| Trường dữ liệu | Ý nghĩa |
|---|---|
| Mã máy/dây chuyền | Xác định nơi phát sinh và liên kết lịch sử |
| Thời gian bắt đầu-kết thúc | Tính thời lượng và phân tích theo ca/thời điểm |
| Trạng thái sản xuất | Lệnh, sản phẩm, công đoạn, tốc độ hoặc setup liên quan |
| Nhóm nguyên nhân cấp 1 | Thiết bị, vận hành, vật tư, chất lượng, kế hoạch, tiện ích... |
| Nguyên nhân chi tiết | Mức đủ để phân tích và hành động |
| Trạng thái xác nhận | Tạm thời, đã xác nhận, chưa xác định |
| Người/bộ phận xác nhận | Trách nhiệm và khả năng truy xuất |
| Phiếu việc liên quan | Liên kết với bảo trì hoặc hành động khắc phục |
| Ảnh hưởng | Sản lượng mất, lệnh trễ, chất lượng hoặc an toàn |
Không phải mọi trường đều phải nhập tay. Thời gian, máy, lệnh và sản phẩm có thể lấy tự động; nguyên nhân và hành động thường cần con người xác nhận.
III. Thiết kế cây nguyên nhân dừng máy
Một danh mục tốt nên có 2-3 cấp, không quá chi tiết ở màn hình đầu.
Ví dụ cấp 1:
- Thiết bị.
- Vận hành.
- Vật tư/phụ tùng sản xuất.
- Chất lượng.
- Kế hoạch/chờ lệnh.
- Thay đổi sản phẩm/setup/vệ sinh.
- Tiện ích và hạ tầng.
- An toàn hoặc nguyên nhân bên ngoài.
Cấp 2 cho nhóm “Thiết bị” có thể gồm cơ khí, điện, điều khiển, khí nén, thủy lực, cảm biến. Cấp 3 chỉ nên thêm khi nhóm đó đủ lớn để cần hành động cụ thể.
Nguyên tắc xây danh mục
- Dựa trên quyết định và trách nhiệm, không dựa trên mong muốn mô tả mọi chi tiết.
- Các lựa chọn phải loại trừ nhau ở mức hợp lý.
- Có “chưa xác định” nhưng phải có quy trình đóng lại.
- Giới hạn nhập tự do; dùng ghi chú để bổ sung ngữ cảnh.
- Rà soát định kỳ những giá trị “khác” và nhóm quá rộng.
- Đào tạo bằng tình huống thật giữa các ca.
IV. Phân biệt hiện tượng, nguyên nhân và hành động
Ba trường thường bị trộn lẫn:
- Hiện tượng: máy không cấp phôi, motor quá nhiệt, cảm biến không nhận.
- Nguyên nhân: dây tín hiệu lỏng, bạc đạn kẹt, vật tư sai kích thước.
- Hành động: siết đầu nối, thay bạc đạn, điều chỉnh tiêu chuẩn vật tư.
Nếu chỉ ghi “kẹt máy - đã xử lý”, dữ liệu khó dùng cho RCA hoặc tri thức bảo trì. Form nên hướng dẫn người dùng ghi ba lớp này riêng biệt.
V. Dashboard dừng máy nên có gì?
Góc nhìn điều hành trong ca
- Tổng dừng so với mục tiêu.
- Máy đang dừng và thời lượng hiện tại.
- Sản lượng/tiến độ bị ảnh hưởng.
- Sự kiện chưa có nguyên nhân hoặc chưa xác nhận.
- Danh sách hành động cần ưu tiên.
Góc nhìn cải tiến theo tuần/tháng
- Pareto tổng thời gian theo nguyên nhân.
- Pareto số lần dừng.
- Top máy theo tổng dừng và số lần.
- Dừng theo ca, sản phẩm, lệnh hoặc khung giờ.
- MTTR, MTBF cho thiết bị phù hợp.
- Tỷ lệ dừng có phiếu bảo trì và tỷ lệ lỗi lặp lại.
- Xu hướng trước-sau hành động cải tiến.
Không nên chỉ xếp hạng “máy hỏng nhiều nhất”. Một máy hỏng nhiều lần nhưng ngắn khác với máy hỏng ít nhưng làm dừng cả dây chuyền. Nên kết hợp tần suất, thời lượng, ảnh hưởng sản lượng và mức độ trọng yếu.
VI. Chu trình cải tiến downtime hằng tuần
Bước 1: kiểm tra chất lượng dữ liệu
Trước khi phân tích nguyên nhân, kiểm tra sự kiện thiếu mã, thời lượng bất thường, nguyên nhân chưa xác nhận và chênh lệch với trạng thái máy.
Bước 2: chọn một vài tổn thất lớn
Dùng Pareto để tập trung 20% nhóm gây phần lớn tổn thất. Không mở quá nhiều hành động cùng lúc.
Bước 3: phân tích theo ngữ cảnh
Xem dừng xảy ra ở ca nào, sản phẩm nào, sau setup hay sau PM, có lặp lại trên cùng bộ phận hay không.
Bước 4: xác nhận tại hiện trường
Dữ liệu chỉ gợi ý. Nhóm sản xuất, bảo trì và chất lượng cần kiểm tra thực tế và xác nhận nguyên nhân.
Bước 5: giao hành động với thời hạn
Hành động có thể là sửa thiết bị, thay đổi PM, đào tạo, sửa tiêu chuẩn vật tư, cải thiện setup hoặc điều chỉnh quy trình.
Bước 6: kiểm tra hiệu lực
Theo dõi cùng nhóm nguyên nhân sau 2-4 tuần. Nếu không giảm, nguyên nhân hoặc hành động có thể chưa đúng.
VII. Ví dụ minh họa
Giả sử dashboard cho thấy dây chuyền A có 620 phút dừng trong tháng:
- 210 phút: kẹt phôi tại máy M03.
- 160 phút: chờ vật tư.
- 95 phút: thay đổi sản phẩm.
- 155 phút: các nguyên nhân khác.
Khi đi sâu, 210 phút kẹt phôi gồm 38 sự kiện ngắn, tập trung ở sản phẩm P2 và ca đêm. Nhóm kiểm tra phát hiện độ ẩm vật tư và cách setup đầu ca chưa ổn định. Hành động không chỉ là “bảo trì máy”; nó bao gồm tiêu chuẩn vật tư, checklist setup và đào tạo ca.
Ví dụ cho thấy dữ liệu giúp chuyển cuộc tranh luận từ “máy hay vận hành?” sang một chuỗi bằng chứng có thể kiểm tra.
VIII. Khi nào nên tự động lấy trạng thái từ máy?
Nên ưu tiên tự động nếu:
- Sự kiện nhiều và dừng ngắn khó ghi tay.
- Thời điểm bắt đầu-kết thúc cần chính xác.
- Người vận hành không thể nhập trong lúc xử lý sự cố.
- Dữ liệu trạng thái đã có ở PLC/SCADA.
Tuy nhiên, máy chỉ cho biết trạng thái, không luôn biết nguyên nhân nghiệp vụ. Một kiến trúc phổ biến là hệ thống tự tạo sự kiện dừng, sau đó người dùng chọn hoặc xác nhận nguyên nhân trong thời gian phù hợp.
IX. AI có thể hỗ trợ phân tích dừng máy ở đâu?
Sau khi dữ liệu đủ tốt, AI có thể:
- Gợi ý nhóm nguyên nhân từ mô tả sự cố.
- Tìm các sự kiện tương tự trong lịch sử.
- Phát hiện dừng tăng bất thường theo ca, sản phẩm hoặc máy.
- Tóm tắt các nhóm tổn thất chính cho cuộc họp.
- Gợi ý tài liệu hoặc phiếu bảo trì liên quan.
- Xác định mẫu lặp lại mà dashboard thông thường khó thấy.
AI không nên tự kết luận nguyên nhân gốc hoặc tự đóng phiếu. Kết quả cần kèm dữ liệu bằng chứng và được người nghiệp vụ xác nhận.
X. KPI để đánh giá chương trình giảm dừng máy
- Tổng thời gian dừng và số lần dừng.
- Dừng theo nhóm nguyên nhân.
- Tỷ lệ sự kiện có nguyên nhân xác nhận.
- Thời gian trung bình để xác nhận nguyên nhân.
- MTTR/MTBF với nhóm thiết bị phù hợp.
- Tỷ lệ lỗi lặp lại.
- Sản lượng mất hoặc chi phí cơ hội do dừng.
- Tỷ lệ hành động cải tiến hoàn thành và có hiệu lực.
Không nên đặt mục tiêu giảm tổng dừng mà không biết nhóm nào sẽ được tác động.
XI. Checklist bắt đầu trong 30 ngày
- Thống nhất định nghĩa dừng và ngưỡng ghi nhận.
- Chọn một dây chuyền và danh sách thiết bị.
- Xây cây nguyên nhân phiên bản 1.0.
- Thiết kế form tối thiểu và người xác nhận.
- Lấy baseline 4-8 tuần nếu có.
- Xây dashboard Pareto và danh sách sự kiện chưa xác nhận.
- Đưa dashboard vào cuộc họp hằng ngày/tuần.
- Chọn một nhóm nguyên nhân để cải tiến và đo lại.
XII. Câu hỏi thường gặp
Nên phân tích số lần dừng hay tổng thời gian dừng?
Cả hai. Tổng thời gian cho biết thiệt hại lớn; số lần giúp thấy các dừng ngắn lặp lại. Có thể thêm sản lượng mất và mức trọng yếu để ưu tiên đúng.
Có nên yêu cầu người vận hành chọn nguyên nhân ngay khi máy dừng?
Không phải lúc nào. Trong sự cố khẩn cấp, ưu tiên an toàn và khôi phục. Có thể cho phép chọn nguyên nhân tạm thời rồi yêu cầu người phù hợp xác nhận sau.
Dừng máy do setup có nên tính chung với breakdown không?
Không nên trộn nếu muốn có hành động đúng. Setup, chờ vật tư, lỗi thiết bị và chất lượng nên được phân nhóm rõ, dù tất cả đều ảnh hưởng Availability.
Có cần AI để giảm downtime không?
Không. Nhiều nhà máy có thể tạo giá trị lớn chỉ bằng chuẩn hóa dữ liệu, Pareto, quy trình xác nhận và hành động. AI là lớp bổ sung khi dữ liệu và nhu cầu phân tích đã trưởng thành.
Bài viết được biên tập từ ebook “Từ số hóa đến AI - Sổ tay chuẩn bị cho nhà máy”, Vietsoft, 06/2026.
Hãy bắt đầu bằng việc đánh giá nhanh mức sẵn sàng AI của nhà máy hoặc tải E-book “Từ Số Hóa Đến AI” để tham khảo cách xây dựng lộ trình Smart Factory phù hợp.
