Bài toán nào chưa nên ứng dụng bằng AI trong nhà máy?

I. Tám dấu hiệu chưa nên dùng AI

1. Không có vấn đề hoặc KPI cụ thể

Mục tiêu “ứng dụng AI để hiện đại hóa” không đủ. Cần biết muốn giảm downtime, rút ngắn tìm tài liệu, cải thiện OEE hay phát hiện lỗi nào.

2. Dữ liệu nền không đáng tin

Nếu mỗi bộ phận có một số OEE, downtime thiếu lý do hoặc work order không có nguyên nhân, AI sẽ khuếch đại sự không nhất quán.

3. Quy trình chưa rõ

Nếu không biết ai xác nhận, ai hành động và khi nào đóng việc, AI không có điểm để tích hợp vào workflow.

4. Vấn đề có quy tắc rõ và ổn định

Nếu chỉ cần cảnh báo “PM quá hạn” hoặc “nhiệt độ vượt 80°C”, rule đơn giản thường rẻ, dễ giải thích và đáng tin hơn AI.

5. Khối lượng dữ liệu/trường hợp quá ít

Một failure chỉ xảy ra một lần trong nhiều năm khó tạo mô hình dự báo. Có thể dùng FMEA, inspection hoặc knowledge capture thay thế.

6. Không có owner xử lý output

Cảnh báo hoặc câu trả lời không có người nhận, SLA và action sẽ trở thành noise.

7. Rủi ro cao nhưng chưa có governance

Use case liên quan an toàn, chất lượng critical hoặc điều khiển cần phân quyền, approval, test và incident process trước.

8. Không có khả năng duy trì

Nếu không có người cập nhật tài liệu, dữ liệu, model/prompt, quyền và chi phí, pilot có thể tốt nhưng nhanh chóng xuống chất lượng.

II. Ma trận chọn công cụ

Đặc điểm bài toán	Công cụ nên ưu tiên
Quy trình chưa rõ	Process mapping, SOP, RACI
Ghi nhận và giao việc rời rạc	CMMS/MES/workflow software
Báo cáo chậm, công thức rõ	Dashboard/BI/automation
Điều kiện cảnh báo cố định	Rule/threshold
Phân tích thống kê có giả thuyết rõ	Analytics/statistics
Nhiều biến, pattern động	ML/anomaly detection
Tài liệu lớn, hỏi đáp ngôn ngữ tự nhiên	AI Copilot/RAG
Quyết định an toàn-critical	Human-controlled system, AI chỉ hỗ trợ giới hạn

Một dự án có thể kết hợp nhiều lớp. Không cần chọn “AI hoặc không AI” cho toàn bộ hệ thống.

III. Ví dụ 1: PM thường xuyên quá hạn

Chưa cần AI khi

Chưa có lịch PM chuẩn.
Không có owner và nhắc việc.
Sản xuất/bảo trì chưa thống nhất cửa sổ dừng.
Work order không được đóng đúng.

Giải pháp trước: CMMS, calendar, notification, dashboard PM compliance và quy trình escalation.

Có thể dùng AI sau khi

Có lịch sử PM, failure và operating hours.
Muốn phân tích chu kỳ nào không phù hợp.
Cần ưu tiên work dựa trên criticality và rủi ro.

IV. Ví dụ 2: Báo cáo sản xuất chậm

Nếu nhân viên copy nhiều Excel cuối ca, giải pháp đầu tiên là chuẩn hóa nguồn và tự động dashboard. AI tóm tắt báo cáo chỉ có ích sau khi số liệu được tạo đúng và đúng giờ.

V. Ví dụ 3: Không tìm được tài liệu

Nếu thư mục lộn xộn, nhiều bản trùng và không có owner, AI Copilot sẽ truy xuất hỗn loạn. Bước đầu là inventory, version, metadata, quyền và tài liệu hiệu lực.

Sau đó AI mới giúp hỏi đáp và tìm đúng đoạn nhanh hơn.

VI. Ví dụ 4: Dự báo hỏng mọi máy

Nếu chưa có criticality, failure mode, sensor và business case, không nên làm predictive maintenance toàn nhà máy. Có thể bắt đầu bằng bad actor analysis, PM compliance và condition monitoring cho thiết bị trọng yếu.

VII. Ví dụ 5: Cảnh báo OEE thấp

Nếu mục tiêu chỉ là báo khi OEE dưới 70%, rule đủ dùng. AI phù hợp hơn khi cần baseline theo sản phẩm/ca, phân tích nhiều chiều và giảm false alarm.

VIII. Nguyên tắc “minimum sufficient technology”

Chọn giải pháp đơn giản nhất đáp ứng:

Độ chính xác cần thiết.
Độ trễ cần thiết.
Khả năng giải thích.
Chi phí chấp nhận được.
Năng lực vận hành.
Mức rủi ro.

Giải pháp đơn giản tạo giá trị sớm và xây dữ liệu cho bước sau. Điều này không chống AI; nó làm AI được dùng đúng chỗ.

IX. Readiness gate trước khi làm AI

Gate 1: Business

Vấn đề và KPI rõ.
Baseline có thể đo.
Owner và người dùng xác định.
Giá trị đủ lớn.

Gate 2: Process

Workflow và decision point rõ.
Input/output và approval xác định.
Có hành động sau AI.

Gate 3: Data/knowledge

Nguồn, chất lượng, quyền và version đủ dùng.
Có context và metadata.
Có test data hoặc câu hỏi thật.

Gate 4: Technology

Kiến trúc, integration, performance và cost phù hợp.
Có logging và monitoring.

Gate 5: Governance

Risk tier, human-in-the-loop, security và incident rõ.
Có người duy trì.

Nếu một gate critical chưa đạt, nên làm nền trước hoặc thu hẹp scope.

X. Cách đánh giá AI có thật sự cần thiết

Hỏi năm câu:

Bài toán có thể giải bằng rule hoặc dashboard không?
AI có cải thiện đủ lớn về chất lượng, tốc độ hoặc quy mô không?
Output AI có dẫn đến quyết định/action cụ thể không?
Có thể kiểm chứng và giám sát không?
TCO và rủi ro có hợp lý so với benefit không?

Nếu câu trả lời phần lớn là không, use case chưa đủ mạnh.

XI. Khi AI vẫn hữu ích dù dữ liệu chưa hoàn hảo

Dữ liệu chưa hoàn hảo không có nghĩa phải chờ. Có thể bắt đầu ở phạm vi nhỏ:

AI Copilot với một bộ tài liệu đã duyệt.
Phân loại mô tả work order rồi SME review.
Tóm tắt báo cáo từ nguồn đã chuẩn.
Phân tích downtime một dây chuyền.
Anomaly pilot trên một asset critical.

Điều kiện là phải mô tả giới hạn và dùng pilot để cải thiện nền, không tuyên bố đã sẵn sàng toàn diện.

XII. Chi phí cơ hội khi dùng AI quá sớm

Đội dự án bỏ thời gian vào model thay vì sửa quy trình.
Người dùng mất niềm tin vì câu trả lời sai.
Dữ liệu nhạy cảm được đưa vào hệ thống chưa kiểm soát.
Chi phí cloud/AI tăng mà không có KPI.
Dashboard và master data vẫn không được hoàn thiện.
Lãnh đạo kết luận sai rằng “AI không hiệu quả”.

Một pilot thất bại do readiness kém có thể làm mất cơ hội cho use case tốt hơn sau này.

XIII. Kế hoạch 30 ngày để quyết định có dùng AI không

Tuần 1: Chọn vấn đề

Phỏng vấn owner và người dùng.
Ghi KPI, baseline và thiệt hại.
Vẽ decision/workflow.

Tuần 2: Kiểm tra dữ liệu và phương án đơn giản

Inventory nguồn.
Đánh giá quality/permission.
Thử rule, dashboard hoặc process change.

Tuần 3: Thiết kế AI use case tối thiểu

User, input, output, risk tier.
Bộ test 20-50 case thật.
Kiến trúc và cost estimate.

Tuần 4: Go/no-go

So sánh benefit, feasibility, risk và TCO.
Chọn pilot, làm nền hoặc dừng.
Chốt KPI và tiêu chí mở rộng.

Quyết định “chưa làm AI” có thể là kết quả tốt nếu giúp ưu tiên đúng nền tảng.

XIV. Những bài toán thường phù hợp với AI hơn

Tìm kiếm/tra cứu trong nhiều tài liệu có kiểm soát.
Phân loại văn bản hoặc case với khối lượng lớn.
Phát hiện pattern đa chiều vượt rule cố định.
Dự báo/ước tính khi có dữ liệu và signal đủ.
Tóm tắt và hỗ trợ phân tích có nguồn.
Ưu tiên cảnh báo hoặc hành động khi có feedback loop.

Điểm chung: AI cải thiện khả năng xử lý dữ liệu/tri thức, không thay thế nền tảng vận hành.

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

Bắt đầu từ công nghệ/model.
Gọi mọi automation là AI.
Dùng AI cho công thức KPI đơn giản.
Không so sánh phương án rule/dashboard.
Không có owner và baseline.
Không tính chi phí duy trì.
Dùng AI ở use case critical mà không governance.
Pilot quá rộng.
Không có tiêu chí dừng.

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

Dữ liệu chưa chuẩn có nên dừng mọi thử nghiệm AI không?

Không. Có thể chọn phạm vi nhỏ với dữ liệu đã kiểm tra và dùng pilot để cải thiện. Nhưng phải công khai giới hạn và không mở rộng khi chất lượng chưa đạt.

Dashboard và AI có cạnh tranh nhau không?

Không. Dashboard là lớp quan sát và metric; AI có thể bổ sung phân tích, hỏi đáp hoặc dự báo. Dashboard tốt thường là nền cho AI analytics.

Rule đơn giản có bị xem là lạc hậu không?

Không. Rule dễ giải thích, kiểm thử và duy trì. Nếu rule giải quyết tốt vấn đề, đó là lựa chọn kỹ thuật đúng.

Khi nào nên xem lại quyết định chưa dùng AI?

Khi quy trình/dữ liệu đã cải thiện, khối lượng tăng, rule không còn đủ hoặc xuất hiện use case có giá trị và owner rõ. Nên review theo roadmap, không chạy theo xu hướng.

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.