Series Từ số hóa đến AI #29: Dashboard tiến độ sản xuất thời gian thực cần những dữ liệu nào?

I. Phân biệt real-time và near-real-time

Real-time thường ám chỉ dữ liệu cập nhật gần như ngay lập tức, phù hợp với trạng thái máy, alarm hoặc điều khiển quá trình.

Near-real-time là cập nhật theo khoảng ngắn như 1, 5, 15 hoặc 30 phút. Với nhiều quyết định quản lý sản xuất, near-real-time đã đủ nếu độ trễ được biết và phù hợp nhịp phản ứng.

Câu hỏi cần đặt là:

• Nếu dữ liệu trễ 5 phút, quyết định có thay đổi không?
• Người dùng cần phản ứng trong bao lâu?
• Nguồn dữ liệu tự động hay phải xác nhận thủ công?
• Chi phí và độ phức tạp của cập nhật nhanh hơn có tạo giá trị tương xứng không?

Không nên quảng bá “real-time” nếu dữ liệu nguyên nhân vẫn được nhập cuối ca.

II. Bắt đầu từ quyết định của từng vai trò

Người vận hành

Cần biết lệnh hiện tại, target theo giờ, sản lượng, bất thường và việc cần làm tiếp theo.

Trưởng ca

Cần biết dây chuyền/công đoạn nào lệch kế hoạch, dừng bao lâu, thiếu vật tư hay lỗi chất lượng, và hành động nào đang mở.

Quản đốc

Cần nhìn nhiều dây chuyền, xu hướng trong ngày, năng lực còn lại và nguy cơ ảnh hưởng đơn hàng.

Ban giám đốc/kế hoạch

Cần bức tranh tổng quan: mức hoàn thành, lệnh rủi ro, nguyên nhân chính và dự kiến giao hàng. Không cần mọi tín hiệu máy trên màn hình chính.

Dashboard theo vai trò tránh tình trạng một màn hình có quá nhiều biểu đồ nhưng không hỗ trợ hành động.

III. Nhóm dữ liệu 1: Lệnh sản xuất và kế hoạch

Tối thiểu gồm:

• Mã lệnh, sản phẩm, phiên bản và khách hàng nếu cần.
• Số lượng kế hoạch và deadline.
• Dây chuyền, công đoạn, routing.
• Thời gian bắt đầu/kết thúc kế hoạch.
• Thứ tự ưu tiên và trạng thái.
• Định mức cycle time hoặc tốc độ chuẩn.
• Thời gian changeover dự kiến.

ERP thường là nguồn kế hoạch, nhưng cần làm rõ tần suất đồng bộ và cách xử lý khi điều độ thay đổi.

IV. Nhóm dữ liệu 2: Sản lượng thực tế và trạng thái

Dữ liệu nên cho biết:

• Sản lượng đạt, lỗi, rework và tổng đếm.
• Timestamp hoặc khoảng thời gian ghi nhận.
• Lệnh, công đoạn, máy/dây chuyền và ca.
• Trạng thái: chờ, setup, chạy, dừng, hold, hoàn thành.
• Người hoặc hệ thống xác nhận.

Sản lượng có thể lấy tự động từ PLC/máy đếm, nhập thủ công hoặc kết hợp. Nếu nhập tay, cần thiết kế tần suất và validation phù hợp.

V. Nhóm dữ liệu 3: Thời gian chạy, dừng và nguyên nhân

Chỉ biết sản lượng thấp chưa đủ. Cần biết thời gian mất ở đâu:

• Planned production time.
• Run time và stop time.
• Sự kiện dừng, bắt đầu/kết thúc.
• Nhóm nguyên nhân: thiết bị, vật tư, chất lượng, setup, kế hoạch, nhân lực.
• Người xác nhận và trạng thái điều tra.
• Liên kết work order nếu liên quan bảo trì.

Dữ liệu trạng thái có thể tự động, nhưng nguyên nhân thường cần người gần hiện trường xác nhận.

VI. Nhóm dữ liệu 4: Tốc độ và cycle time

Dashboard cần so sánh tốc độ/cycle time thực tế với chuẩn theo sản phẩm hoặc công đoạn. Nếu dùng một tốc độ chuẩn cho mọi sản phẩm, cảnh báo có thể sai.

Cần lưu:

• Ideal/standard cycle time và nguồn phê duyệt.
• Actual cycle time theo khoảng thời gian.
• Micro-stop hoặc chạy chậm.
• Thời gian changeover.
• Điều kiện ảnh hưởng: sản phẩm, khuôn, ca, máy.

Performance loss thường khó nhìn nếu chỉ theo dõi dừng dài.

VII. Nhóm dữ liệu 5: Chất lượng

Sản lượng hoàn thành không đồng nghĩa sản lượng đạt. Cần:

• Good count, reject, rework.
• Mã lỗi và công đoạn phát sinh/phát hiện.
• Hold hoặc waiting for inspection.
• Thời gian chờ quyết định chất lượng.
• Phạm vi lô ảnh hưởng.

Một lệnh có thể “đạt số lượng tổng” nhưng vẫn có nguy cơ trễ giao nếu nhiều sản phẩm phải rework hoặc chờ giải phóng.

VIII. Nhóm dữ liệu 6: Vật tư, nhân lực và ràng buộc

Tùy use case, dashboard có thể cần:

• Vật tư đã cấp, thiếu hoặc dự kiến đến.
• Tình trạng khuôn/jig/dụng cụ.
• Số người thực tế so với kế hoạch.
• Công đoạn upstream/downstream bị nghẽn.
• Lịch bảo trì hoặc downtime dự kiến.
• Hàng chờ/WIP giữa công đoạn.

Không nên đưa mọi dữ liệu vào màn hình chính. Chỉ thêm khi nó giúp giải thích và hành động với tiến độ.

IX. Các chỉ số và phép tính cốt lõi

Plan attainment

Tỷ lệ hoàn thành = Sản lượng đạt thực tế / Sản lượng kế hoạch đến thời điểm hiện tại

Cần dùng kế hoạch “đến thời điểm hiện tại”, không chỉ kế hoạch cả ca.

Variance

Chênh lệch = Thực tế - Kế hoạch tích lũy

Hiển thị bằng đơn vị sản phẩm và thời gian tương đương giúp người dùng hiểu mức trễ.

Required rate

Tốc độ cần đạt = Số lượng còn lại / Thời gian sản xuất khả dụng còn lại

Nếu required rate vượt khả năng thực tế, lệnh có nguy cơ trễ dù hiện tại chênh lệch chưa lớn.

Projected completion

Có thể ước tính từ tốc độ gần đây, downtime, changeover và chất lượng. Đây là dự báo, cần hiển thị giả định và độ tin cậy.

OEE hoặc các thành phần

OEE hữu ích để hiểu Availability, Performance, Quality, nhưng dashboard tiến độ không nên biến thành màn hình OEE thuần túy. Mục tiêu chính vẫn là lệnh và hành động.

X. Cảnh báo nên được thiết kế theo hành động

Một cảnh báo tốt cần có:

• Điều kiện rõ: lệch kế hoạch bao nhiêu, kéo dài bao lâu.
• Mức độ ưu tiên.
• Người nhận theo ca/khu vực.
• Thông tin bối cảnh: lệnh, máy, nguyên nhân gần nhất.
• Hành động hoặc workflow xác nhận.
• Cơ chế đóng và ghi kết quả.
• Chống cảnh báo lặp và quá tải.

Ví dụ, không nên gửi cảnh báo mỗi phút khi máy đã có work order và người xử lý. Dashboard có thể chuyển trạng thái sang “đang xử lý” và theo dõi thời gian.

XI. Bố cục dashboard theo ca

Một màn hình trưởng ca có thể gồm:

1. Plan vs actual toàn ca và theo giờ.
2. Lệnh đang chạy, số lượng còn lại, projected finish.
3. Danh sách lệnh/công đoạn có nguy cơ trễ.
4. Dừng máy đang mở, thời lượng và owner.
5. Top nguyên nhân mất thời gian trong ca.
6. Lỗi chất lượng và hold.
7. Thiếu vật tư/dụng cụ.
8. Hành động đang mở và thời hạn.

Màu sắc nên dùng tiết chế. Mỗi trạng thái đỏ cần gắn với điều kiện và hành động, không chỉ làm màn hình “nổi bật”.

XII. Nguồn dữ liệu tự động và thủ công nên phối hợp thế nào?

Lấy tự động khi dữ liệu cần nhanh, khối lượng lớn và ít cần judgment: trạng thái máy, đếm sản lượng, tốc độ, alarm.

Nhập hoặc xác nhận bởi con người khi dữ liệu là nguyên nhân, quyết định hoặc bối cảnh: lý do dừng, disposition chất lượng, thay đổi kế hoạch, lý do thiếu vật tư.

Thiết kế tốt thường dùng máy để phát hiện sự kiện và con người để xác nhận ý nghĩa. Form phải ngắn và xuất hiện đúng thời điểm.

XIII. AI có thể dự báo nguy cơ trễ ra sao?

Khi dữ liệu đủ tốt, AI/analytics có thể dùng:

• Tốc độ gần đây và lịch sử theo sản phẩm.
• Mẫu downtime và changeover.
• Tỷ lệ lỗi/rework.
• WIP và năng lực công đoạn sau.
• Tình trạng vật tư và nguồn lực.
• Lịch bảo trì và backlog.

Kết quả có thể là xác suất hoàn thành đúng hạn hoặc danh sách yếu tố chính kéo trễ. AI nên hỗ trợ ưu tiên, không tự thay đổi kế hoạch nếu chưa có quy trình phê duyệt.

XIV. Pilot dashboard trong 8-12 tuần

• Chọn một dây chuyền và 3-5 loại lệnh đại diện.
• Chốt định nghĩa plan, actual, run/stop và good count.
• Map nguồn dữ liệu và độ trễ.
• Chuẩn hóa nguyên nhân dừng tối thiểu.
• Xây màn hình cho người vận hành và trưởng ca.
• Chạy trong họp ca, ghi phản hồi hằng ngày.
• Đo thời gian phát hiện trễ, độ đầy đủ dữ liệu và số báo cáo tay giảm.
• Mở rộng sau khi dashboard được dùng để giao hành động.

XV. KPI đánh giá dashboard

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

• Gọi là real-time nhưng dữ liệu quan trọng nhập cuối ca.
• Chỉ hiển thị sản lượng, không có trạng thái và nguyên nhân.
• Dùng cycle time chuẩn không theo sản phẩm.
• Quá nhiều biểu đồ cho ban giám đốc, thiếu danh sách hành động cho trưởng ca.
• Cảnh báo mọi biến động nhỏ, gây alarm fatigue.
• Không thống nhất source of truth giữa ERP và hiện trường.
• Không có workflow xử lý dữ liệu sai.
• Đánh giá thành công bằng việc dashboard được mở, không phải quyết định được cải thiện.

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

Có cần kết nối PLC mới làm dashboard tiến độ không?

Không bắt buộc. Có thể bắt đầu bằng dữ liệu lệnh và cập nhật sản lượng có kỷ luật. PLC/SCADA hữu ích khi cần trạng thái, đếm và tốc độ tự động.

Cập nhật bao lâu một lần là đủ?

Phụ thuộc thời gian phản ứng. Dây chuyền nhanh có thể cần phút; quy trình dài có thể 15-60 phút. Cần định nghĩa dựa trên quyết định, không theo khẩu hiệu.

Dashboard có thay thế họp ca không?

Không. Dashboard giúp mọi người dùng cùng dữ liệu và tập trung vào ngoại lệ, hành động. Nhịp họp và trách nhiệm vẫn cần được thiết kế.

Có nên hiển thị OEE trên dashboard tiến độ?

Có thể, nhưng OEE nên hỗ trợ giải thích tổn thất. Màn hình chính vẫn cần ưu tiên lệnh, chênh lệch, dự kiến hoàn thành và hành động.