Series Từ số hóa đến AI #38: Vai trò quản lý cấp trung trong dự án số hóa nhà máy

I. Vì sao quản lý cấp trung là “điểm truyền lực” của dự án?

Ban lãnh đạo quyết định mục tiêu và ngân sách. Đội IT/OT bảo đảm hạ tầng, tích hợp và vận hành kỹ thuật. Nhà cung cấp cấu hình, hướng dẫn và hỗ trợ. Tuy nhiên, quản lý cấp trung là người biến các thành phần đó thành hành vi hằng ngày.

Họ thường nắm bốn quyền lực thực tế:

1. Quyết định người dùng phải làm gì trong ca.
2. Quyết định báo cáo nào được dùng trong họp.
3. Xác nhận dữ liệu nào đủ tin cậy để ra quyết định.
4. Ưu tiên nguồn lực để xử lý vướng mắc và cải tiến quy trình.

Nếu bốn quyền lực này không được huy động, phần mềm dễ trở thành một kênh nhập liệu phụ. Hệ thống có thể có tài khoản, chức năng và dashboard nhưng không có thói quen sử dụng.

II. Vai trò của quản lý cấp trung trước khi triển khai

Chọn đúng bài toán thay vì chọn nhiều chức năng

Quản lý cấp trung phải giúp đội dự án mô tả vấn đề bằng ngôn ngữ vận hành: dừng máy ở đâu, báo cáo chậm bao lâu, lỗi nào lặp lại, công việc PM nào thường trễ, quyết định nào đang thiếu dữ liệu.

Một yêu cầu như “cần dashboard hiện đại” quá mơ hồ. Một yêu cầu tốt hơn là: “Trưởng ca cần biết trong 15 phút đầu khi sản lượng lệch kế hoạch và nguyên nhân chính là máy, vật tư hay chất lượng.”

Chốt baseline và KPI

Không có baseline, dự án khó chứng minh giá trị. Quản lý cấp trung nên xác nhận số hiện tại và cách đo, ví dụ:

• Thời gian tổng hợp báo cáo cuối ca.
• Tỷ lệ phiếu bảo trì có đủ nguyên nhân và hành động.
• Tỷ lệ PM hoàn thành đúng hạn.
• Tỷ lệ sự kiện dừng máy có mã nguyên nhân.
• Số cuộc gọi hoặc tin nhắn phải dùng để điều phối công việc.
• Thời gian phát hiện đơn hàng có nguy cơ trễ.

Làm rõ quy trình và quyền quyết định

Trước khi cấu hình, cần trả lời: ai tạo, ai xác nhận, ai duyệt, khi nào dữ liệu được xem là chính thức, trường nào bắt buộc và trường hợp ngoại lệ xử lý thế nào. Quản lý cấp trung không nên giao toàn bộ việc này cho IT hoặc nhà cung cấp vì họ là người hiểu nhịp vận hành thực tế.

III. Vai trò trong giai đoạn thiết kế và pilot

Đại diện cho người dùng nhưng không thiết kế theo mọi ngoại lệ

Quản lý cấp trung cần thu thập phản hồi từ người dùng hiện trường, nhưng cũng phải giữ phạm vi. Nếu mọi trường hợp riêng đều biến thành một chức năng tùy chỉnh, pilot sẽ chậm và khó mở rộng.

Một nguyên tắc thực tế là ưu tiên luồng chuẩn đáp ứng phần lớn tình huống, sau đó thiết kế ngoại lệ quan trọng bằng quyền, ghi chú hoặc bước escalation rõ ràng.

Kiểm thử bằng tình huống thật

Không chỉ kiểm tra nút bấm. Hãy chạy các tình huống như:

• Máy dừng giữa ca và cần tạo yêu cầu bảo trì.
• Kỹ thuật viên cần ghi nguyên nhân, phụ tùng và thời gian khôi phục.
• Trưởng ca cần xác nhận lý do dừng máy.
• Một phiếu bị nhập sai và cần sửa có audit trail.
• Internet gián đoạn hoặc thiết bị nhập liệu gặp lỗi.
• Người thay ca cần tiếp nhận công việc chưa hoàn thành.

Quản lý cấp trung nên xác nhận rằng workflow giúp công việc rõ hơn, không chỉ “chạy được”.

Bảo vệ thời gian cho pilot

Người dùng thường phải vừa vận hành vừa tham gia dự án. Nếu không có thời gian được phân bổ, họ sẽ xem kiểm thử và làm sạch dữ liệu là việc phụ. Quản lý cần bố trí ca thử, người đầu mối và thời gian phản hồi cụ thể.

IV. Vai trò sau go-live: nơi dự án thường thành công hoặc thất bại

Go-live không phải điểm kết thúc. Đây là lúc thói quen cũ và mới cạnh tranh trực tiếp.

Dùng hệ thống làm nguồn chính thức

Quản lý cấp trung cần tuyên bố rõ dữ liệu nào là nguồn chính thức. Ví dụ, phiếu bảo trì trên CMMS là nguồn theo dõi công việc; dashboard sản xuất là nguồn dùng trong họp ca; file Excel cũ chỉ được giữ trong thời gian chuyển tiếp có thời hạn.

Nếu vẫn cho phép nhiều nguồn song song mà không có kế hoạch loại bỏ, người dùng sẽ chọn cách ít ràng buộc nhất.

Họp bằng dashboard và giao hành động trên hệ thống

Mỗi cuộc họp là một tín hiệu về mức độ nghiêm túc của dự án. Khi quản lý hỏi trực tiếp từ dashboard, giao owner và theo dõi deadline trên hệ thống, dữ liệu bắt đầu có giá trị đối với người nhập.

Một cuộc họp tốt nên đi theo chuỗi:

1. Chỉ số nào lệch?
2. Dữ liệu có đủ tin cậy không?
3. Nguyên nhân nào đã được xác nhận?
4. Hành động nào cần làm, ai chịu trách nhiệm, khi nào hoàn thành?
5. Kết quả được ghi lại ở đâu?

Phản hồi chất lượng dữ liệu, không chỉ yêu cầu nhập đủ

Khi dữ liệu thiếu, cần phân biệt nguyên nhân:

• Form quá dài hoặc khó dùng.
• Danh mục nguyên nhân không phản ánh thực tế.
• Người dùng chưa hiểu ý nghĩa trường dữ liệu.
• Quy trình giao trách nhiệm chưa rõ.
• Thiết bị hoặc kết nối bất tiện.
• Dữ liệu nhập xong không được sử dụng lại.

Chỉ nhắc “phải nhập đủ” mà không xử lý nguyên nhân sẽ tạo dữ liệu hình thức.

V. Ma trận trách nhiệm gợi ý

RACI cụ thể có thể khác theo nhà máy, nhưng không nên để trách nhiệm “adoption” nằm chung chung ở đội dự án.

VI. Bảy hành vi cho thấy quản lý cấp trung thực sự ủng hộ

1. Tham gia chọn use case và không giao hết cho IT.
2. Dùng dashboard trong cuộc họp định kỳ.
3. Không yêu cầu báo cáo trùng lặp ngoài hệ thống nếu không cần.
4. Kiểm tra chất lượng dữ liệu và phản hồi nguyên nhân thiếu.
5. Ghi nhận người dùng áp dụng tốt, không chỉ phê bình lỗi.
6. Chấp nhận điều chỉnh quy trình khi pilot cho thấy bất hợp lý.
7. Theo dõi hành động đến khi KPI vận hành cải thiện.

Sự ủng hộ được thể hiện bằng hành vi lặp lại, không phải bằng phát biểu trong buổi kick-off.

VII. Kế hoạch 30-60-90 ngày cho quản lý cấp trung

30 ngày đầu: tạo kỷ luật sử dụng

• Chốt nguồn dữ liệu chính thức.
• Dừng hoặc lên lịch dừng báo cáo trùng lặp.
• Họp ngắn hằng ngày bằng dashboard.
• Theo dõi lỗi thao tác và trường dữ liệu thiếu.
• Duy trì kênh hỗ trợ hiện trường.

60 ngày: cải thiện quy trình và dữ liệu

• Phân tích lý do người dùng bỏ bước.
• Rút gọn form và danh mục nếu cần.
• Kiểm tra KPI adoption theo ca/kíp.
• Bổ sung đào tạo theo tình huống khó.
• Chọn 1-2 vấn đề vận hành để cải tiến bằng dữ liệu.

90 ngày: chứng minh giá trị và quyết định mở rộng

• So sánh baseline với kết quả.
• Xác nhận dữ liệu đã đủ tin cậy ở mức nào.
• Chuẩn hóa bài học thành playbook.
• Quyết định mở rộng, giữ phạm vi hoặc điều chỉnh.
• Ghi nhận đóng góp của người dùng và đội nòng cốt.

VIII. KPI nên dùng để đánh giá vai trò quản lý cấp trung

Không nên dùng chỉ số đăng nhập đơn thuần. Người dùng có thể đăng nhập nhưng không hoàn thành workflow có giá trị.

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

• Chỉ mời quản lý cấp trung đến buổi đào tạo cuối cùng.
• Xem họ như người truyền đạt mệnh lệnh thay vì đồng thiết kế quy trình.
• Yêu cầu hệ thống mới nhưng vẫn giữ mọi báo cáo cũ vô thời hạn.
• Dùng dữ liệu thô để phạt cá nhân ngay khi chất lượng dữ liệu chưa ổn.
• Đánh giá dự án theo số chức năng thay vì hành vi và KPI vận hành.
• Không trao quyền xử lý vướng mắc liên phòng ban.
• Không dành thời gian cho quản lý làm vai trò change lead.

X. Checklist dành cho sponsor

Trước khi go-live, sponsor nên kiểm tra:

• Mỗi bộ phận có một quản lý chịu trách nhiệm adoption chưa?
• Quản lý đã tham gia thiết kế workflow và KPI chưa?
• Nguồn dữ liệu chính thức đã được công bố chưa?
• Báo cáo cũ nào sẽ dừng và vào thời điểm nào?
• Cuộc họp nào sẽ chuyển sang dùng dashboard?
• Quản lý có quyền yêu cầu sửa form, danh mục và quy trình không?
• Có KPI adoption và chất lượng dữ liệu theo từng bộ phận không?

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

Quản lý cấp trung không giỏi công nghệ có dẫn dắt được không?

Có. Họ không cần trở thành chuyên gia kỹ thuật. Điều quan trọng là hiểu quy trình, KPI, người dùng và quyết định vận hành; IT và nhà cung cấp hỗ trợ phần công nghệ.

Có nên gắn KPI sử dụng hệ thống vào đánh giá quản lý không?

Có thể, nhưng nên gắn với chất lượng workflow và hiệu quả vận hành, không chỉ số lần đăng nhập. KPI cần được công bố rõ và có giai đoạn ổn định dữ liệu trước khi áp dụng cứng.

Khi nào nên dừng báo cáo Excel cũ?

Khi dữ liệu trên hệ thống đã được đối chiếu, người dùng có phương án xử lý ngoại lệ và quản lý xác nhận nguồn mới đủ tin cậy. Nên có ngày dừng cụ thể thay vì duy trì song song vô thời hạn.

Nếu hai trưởng bộ phận không thống nhất quy trình thì ai quyết định?

Process owner nên đề xuất phương án và sponsor hoặc ban chỉ đạo ra quyết định cuối cùng dựa trên mục tiêu chung của nhà máy. Không nên để nhà cung cấp tự quyết thay nghiệp vụ.