Series Từ số hóa đến AI #40: Nhóm chuyển đổi số nội bộ trong nhà máy cần gồm những ai?

I. Nhóm nội bộ phải chịu trách nhiệm về kết quả, không chỉ phối hợp lịch

Một project team chỉ quản lý kế hoạch, biên bản và lịch họp chưa đủ. Nhóm chuyển đổi số phải làm chủ bốn tài sản lâu dài:

1. Quy trình: cách nhà máy muốn vận hành trên hệ thống.
2. Dữ liệu: định nghĩa, chất lượng, owner và cách sử dụng.
3. Adoption: người dùng có dùng thật và bỏ cách cũ hay không.
4. Năng lực cải tiến: sau go-live có tự điều chỉnh dashboard, danh mục và workflow hay không.

Nhà cung cấp nên là đối tác, không phải người sở hữu bốn tài sản này.

II. Cấu trúc vai trò gợi ý

Sponsor điều hành

Sponsor thường là giám đốc nhà máy, giám đốc vận hành hoặc lãnh đạo có quyền xử lý xung đột liên phòng ban. Họ chốt mục tiêu, phạm vi, ngân sách, mức ưu tiên và nguyên tắc ra quyết định.

Sponsor không cần tham gia mọi cuộc họp, nhưng phải xuất hiện khi đội dự án bị kẹt vì quyền lực, nguồn lực hoặc khác biệt KPI giữa các bộ phận.

Product owner hoặc program lead

Đây là người theo đuổi giá trị đầu-cuối, giữ backlog, ưu tiên yêu cầu và bảo đảm giải pháp phục vụ mục tiêu vận hành. Product owner không nên chỉ là điều phối viên hành chính.

Năng lực quan trọng:

• Hiểu vấn đề sản xuất và dữ liệu.
• Biết phân biệt yêu cầu bắt buộc với mong muốn.
• Có quyền gọi các bộ phận tham gia.
• Theo dõi adoption và KPI sau go-live.

Process owner

Mỗi quy trình chính cần owner nghiệp vụ: bảo trì, sản xuất, chất lượng, kho hoặc năng lượng. Họ quyết định quy trình chuẩn, trường dữ liệu, vai trò duyệt và ngoại lệ.

Không nên để IT hoặc nhà cung cấp quyết định thay process owner về ý nghĩa nghiệp vụ.

Đại diện sản xuất, bảo trì và chất lượng

Những người này cung cấp tình huống thực tế, kiểm thử workflow, chuẩn hóa mã/danh mục và làm super user cho bộ phận. Nên chọn người có uy tín với hiện trường, không chỉ người rảnh.

IT/OT và kiến trúc tích hợp

IT/OT chịu trách nhiệm về tài khoản, hạ tầng, bảo mật, kết nối ERP/PLC/SCADA, backup, monitoring và support model. Họ cần tham gia khảo sát hiện trường để hiểu độ trễ, thiết bị và điều kiện vận hành.

Data owner hoặc data steward

Data owner chịu trách nhiệm định nghĩa và chất lượng của nhóm dữ liệu. Ví dụ, bảo trì sở hữu mã thiết bị và nguyên nhân hỏng; sản xuất sở hữu kế hoạch, sản lượng và dừng máy; chất lượng sở hữu mã lỗi và CAPA.

Data steward thực hiện công việc hằng ngày như kiểm tra trùng mã, mapping, completeness và xử lý yêu cầu thay đổi.

Change/training lead

Người này xây persona, truyền thông, kế hoạch đào tạo, super user, hypercare và theo dõi adoption. Trong dự án nhỏ, vai trò có thể kiêm nhiệm nhưng không được bỏ trống.

III. Ma trận RACI tối thiểu

A = Accountable, R = Responsible, C = Consulted, I = Informed. Ma trận phải được điều chỉnh theo quy mô, nhưng mỗi hoạt động chỉ nên có một người chịu trách nhiệm cuối cùng.

IV. Quyền quyết định cần được công bố

Nhóm dự án dễ chậm khi mọi thay đổi đều phải xin ý kiến nhiều cấp. Nên định nghĩa ngưỡng:

• Process owner được quyết định thay đổi form trong phạm vi quy trình.
• Data owner được phê duyệt mã và mapping.
• IT/OT được quyết định tiêu chuẩn hạ tầng và bảo mật trong policy.
• Product owner ưu tiên backlog và phạm vi sprint/pilot.
• Sponsor quyết định thay đổi ngân sách, phạm vi lớn hoặc xung đột liên phòng ban.

Khi quyền không rõ, nhà cung cấp thường phải chờ hoặc tự suy đoán, dẫn đến rework.

V. Nhịp vận hành của nhóm dự án

Trong giai đoạn thiết kế

• Weekly steering: mục tiêu, rủi ro, quyết định cần sponsor.
• Working session theo quy trình: workflow, dữ liệu, ngoại lệ.
• Data clinic: master data, mapping, completeness.
• Demo/feedback: kiểm tra giải pháp theo tình huống thật.

Trong pilot và go-live

• Daily 15 phút: lỗi, dữ liệu thiếu, blocker và action.
• Dashboard adoption review: user, workflow, data quality.
• Weekly value review: KPI vận hành và bài học.

Sau go-live

• Monthly governance: backlog, thay đổi quy trình, quyền, dữ liệu, license và roadmap.
• Quarterly value review: ROI, adoption, scale-up và use case mới.

Nhịp họp phải gắn với quyết định và hành động, không chỉ cập nhật trạng thái.

VI. Năng lực nội bộ cần xây dần

Không phải nhà máy phải tự làm mọi thứ. Nhưng nên có khả năng tối thiểu:

• Quản lý tài khoản, vai trò và master data.
• Đọc log và phân loại sự cố.
• Kiểm tra chất lượng dữ liệu.
• Điều chỉnh dashboard hoặc yêu cầu thay đổi có cấu trúc.
• Đào tạo người dùng mới.
• Quản lý backlog và release.
• Làm việc với API/tích hợp ở mức quản trị.
• Đánh giá nhà cung cấp và kiểm soát change request.

Năng lực này giảm vendor lock-in và giúp hệ thống tiếp tục phát triển theo vận hành.

VII. Cách chọn thành viên

Một người phù hợp không nhất thiết có chức danh cao nhất. Nên ưu tiên:

• Hiểu quy trình thực tế, kể cả ngoại lệ.
• Có uy tín với đồng nghiệp.
• Có tư duy cải tiến, không chỉ bảo vệ cách cũ.
• Sẵn sàng làm việc với dữ liệu.
• Có thời gian được phân bổ chính thức.
• Có khả năng giải thích và huấn luyện người khác.
• Dám nói khi thiết kế không phù hợp hiện trường.

Không nên chọn toàn bộ nhóm từ IT hoặc chỉ chọn những người đang ít việc.

VIII. Quy mô nhóm theo phạm vi

Pilot một quy trình hoặc dây chuyền

Có thể bắt đầu với 5-8 người nòng cốt: sponsor bán thời gian, product owner, process owner, một vài super user, IT/OT và nhà cung cấp.

Triển khai nhiều module hoặc nhiều nhà máy

Cần mô hình hub-and-spoke: core team chung về kiến trúc, dữ liệu, governance; mỗi nhà máy/bộ phận có local process owner và super user.

Chương trình AI

Ngoài các vai trò trên, cần AI/data owner, SME kiểm chứng, security/privacy và người chịu trách nhiệm bộ test, monitoring, log và escalation.

Quy mô phải theo phạm vi và độ phức tạp, không theo số lượng phòng ban muốn có đại diện.

IX. Deliverable mà nhóm nội bộ phải sở hữu

• Project charter và mục tiêu/KPI.
• Process map phiên bản được phê duyệt.
• Data dictionary và master data owner.
• RACI và decision rights.
• UAT scenario và kết quả kiểm thử.
• Training plan và danh sách super user.
• Cutover/go-live plan.
• Support model và escalation.
• Backlog cải tiến.
• Báo cáo adoption, data quality và value realization.
• Exit/portability plan với nhà cung cấp.

Nếu các tài liệu này chỉ nằm ở phía nhà cung cấp, nhà máy chưa thực sự làm chủ dự án.

X. Mô hình ba tầng governance

Tầng 1: Steering committee

Chốt chiến lược, ngân sách, ưu tiên và xử lý xung đột. Họp ít nhưng quyết định nhanh.

Tầng 2: Core delivery team

Product owner, process owner, IT/OT, data và change lead. Thiết kế, kiểm thử, quản lý backlog và giá trị.

Tầng 3: Super user network

Đại diện theo ca, khu vực hoặc nhà máy. Hỗ trợ người dùng, thu phản hồi, đào tạo và giám sát dữ liệu.

Ba tầng giúp tránh hai cực đoan: mọi việc dồn lên lãnh đạo hoặc mọi việc bị bỏ cho nhóm kỹ thuật.

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

• Xem dự án là việc riêng của IT.
• Có sponsor trên danh nghĩa nhưng không ra quyết định.
• Process owner không có thời gian chính thức.
• Không có data owner cho danh mục dùng chung.
• Super user được chọn nhưng không được trao quyền.
• Nhóm chỉ hoạt động đến go-live rồi giải tán.
• Không có backlog và governance cho thay đổi sau triển khai.
• Nhà cung cấp giữ toàn bộ tài liệu, cấu hình và tri thức.

XII. Checklist khởi động trong hai tuần

1. Chỉ định sponsor và product owner.
2. Xác định process owner và data owner theo phạm vi.
3. Chọn super user từ các ca/khu vực.
4. Công bố thời gian được phân bổ cho thành viên.
5. Hoàn thiện RACI và decision rights.
6. Chốt nhịp họp, kênh quyết định và escalation.
7. Lập danh sách deliverable nội bộ phải sở hữu.
8. Xác định năng lực nào cần nhà cung cấp chuyển giao.
9. Đặt KPI adoption và data quality bên cạnh KPI kỹ thuật.
10. Lên kế hoạch duy trì core team ít nhất 3-6 tháng sau go-live.

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

Nhóm chuyển đổi số có cần là một phòng ban riêng không?

Không nhất thiết. Có thể là nhóm liên chức năng bán thời gian, miễn là có quyền, trách nhiệm và thời gian rõ. Khi chương trình mở rộng, doanh nghiệp có thể hình thành CoE hoặc bộ phận chuyên trách.

IT có nên làm product owner không?

Có thể nếu người đó hiểu vận hành và có quyền ưu tiên nghiệp vụ. Tuy nhiên, với hệ thống sản xuất/bảo trì, product owner thường nên gắn chặt với nghiệp vụ và phối hợp IT thay vì chỉ nhìn từ kỹ thuật.

Có cần giữ nhóm sau khi nhà cung cấp bàn giao không?

Có. Đây là giai đoạn dữ liệu, adoption và backlog bắt đầu phát sinh nhiều nhất. Nhóm nội bộ cần duy trì để ổn định, cải tiến và đánh giá mở rộng.

Một người có thể kiêm nhiều vai trò không?

Có trong dự án nhỏ, nhưng phải tránh xung đột. Ví dụ, người cấu hình hệ thống không nên tự phê duyệt mọi quyền truy cập hoặc tự xác nhận chất lượng nghiệp vụ mà không có process owner.