Phối hợp triển khai chuyển đổi số được tổ chức thế nào?

Điểm quan trọng là trách nhiệm được thiết kế theo kết quả chung của quy trình, không theo ranh giới từng phòng. IT có thể chịu trách nhiệm về nền tảng, tích hợp và vận hành kỹ thuật, nhưng kết quả chuyển đổi thường phụ thuộc thêm vào nghiệp vụ, dữ liệu, kiểm soát, nhân sự và người dùng. Vì vậy, cơ chế phối hợp tốt phải trả lời được bốn câu hỏi ngay trong cách vận hành hằng ngày: ai có quyền quyết định, ai làm, ai phải được tham vấn và ai cần được thông báo.

Quyền quyết định phải được đặt đúng cấp

Cơ chế phối hợp chỉ vận hành ổn định khi quyền quyết định được phân tầng. Những quyết định về mục tiêu, ưu tiên đầu tư, phân bổ nguồn lực hoặc chấp nhận rủi ro thuộc về cấp bảo trợ hoặc ban điều phối chuyển đổi số. Những quyết định về cách thiết kế và vận hành một quy trình xuyên phòng ban nên thuộc về chủ sở hữu quy trình hoặc người chịu trách nhiệm cuối cùng cho kết quả quy trình. Các quyết định tác nghiệp nằm trong phạm vi đã được phê duyệt có thể giao cho nhóm triển khai.

Cách phân tầng này xử lý một vấn đề thường gặp: cùng một việc nhưng nhiều phòng đều có tiếng nói, trong khi không ai có quyền chốt. Khi quyền quyết định không rõ, nhóm triển khai phải xin ý kiến theo từng cấp quản lý chức năng, khiến thời gian chờ tăng và xung đột ưu tiên kéo dài. Ngược lại, nếu mọi quyết định đều đẩy lên lãnh đạo cao nhất, cơ chế sẽ an toàn về hình thức nhưng chậm về vận hành.

Với tổ chức nhỏ, không nhất thiết phải lập thêm một ban chỉ đạo riêng. Một người bảo trợ có thẩm quyền, một chủ sở hữu quy trình và một nhóm liên chức năng có thể đủ. Tổ chức lớn hoặc chương trình có nhiều đơn vị phụ thuộc lẫn nhau mới cần thêm lớp điều phối như văn phòng chuyển đổi, PMO hoặc ban điều phối để xử lý các quyết định vượt phạm vi của một quy trình.

Phân vai theo quy trình thay vì theo phòng ban

Sau khi xác định quyền quyết định, mỗi điểm công việc quan trọng phải có một người chịu trách nhiệm cuối cùng và những bên tham gia được phân biệt rõ. Ma trận RACI là một cách đơn giản để làm việc này:

·         Accountable là người chịu trách nhiệm cuối cùng về kết quả hoặc quyết định

·         Responsible là người trực tiếp thực hiện công việc

·         Consulted là bên phải được tham vấn trước khi chốt

·         Informed là bên cần được cập nhật sau khi quyết định hoặc công việc thay đổi

Giá trị của RACI không nằm ở việc tạo thêm một bảng phân công, mà ở chỗ ngăn tình trạng “trách nhiệm tập thể” biến thành không có chủ sở hữu thực sự. Ví dụ, khi số hóa quy trình phê duyệt mua hàng, bộ phận nghiệp vụ có thể là Accountable cho quy trình, IT Responsible cho cấu hình hệ thống, tài chính và kiểm soát nội bộ là Consulted ở các bước liên quan, còn các đơn vị sử dụng là Informed về thay đổi cách làm.

RACI không nên được dùng quá mức. Nếu áp dụng cho mọi tác vụ nhỏ, nó làm tăng chi phí quản trị. Nên dùng ở các điểm có khả năng gây tranh chấp hoặc tạo phụ thuộc giữa phòng ban, như phê duyệt yêu cầu, thay đổi dữ liệu, chấp nhận rủi ro, nghiệm thu, đưa vào vận hành và xử lý sự cố sau triển khai.

Luồng thông tin phải có một nguồn trạng thái chung

Phối hợp liên phòng ban dễ thất bại khi mỗi bộ phận nắm một phiên bản khác nhau của kế hoạch, yêu cầu hoặc trạng thái công việc. Vì vậy, nhóm triển khai nên có một nguồn trạng thái chung cho các hạng mục đang thực hiện, chẳng hạn backlog, roadmap, bảng tiến độ hoặc hệ thống quản lý công việc dùng chung. Bên cạnh đó, các quyết định quan trọng cần được ghi lại trong decision log để biết quyết định gì đã được chốt, ai chốt, thời điểm nào và dựa trên điều kiện nào.

Nhịp trao đổi nên được tách theo mục đích. Nhóm thực thi cần nhịp ngắn để xử lý phụ thuộc và vướng mắc đang phát sinh; chủ sở hữu quy trình cần nhịp định kỳ để kiểm tra tiến độ, chất lượng bàn giao và các quyết định liên phòng ban; cấp bảo trợ chỉ nên nhận các vấn đề vượt thẩm quyền của nhóm hoặc ảnh hưởng đến mục tiêu, ngân sách, nguồn lực và rủi ro. Việc đưa mọi vấn đề lên cùng một cuộc họp thường làm tăng lượng thông tin nhưng không làm rõ trách nhiệm.

Một nguyên tắc hữu ích là trạng thái công việc phải có thể kiểm tra mà không phụ thuộc vào trí nhớ của một cá nhân. Khi người khác có thể nhìn vào cùng một nguồn dữ liệu để biết việc nào đang chờ ai, quyết định nào chưa chốt và điểm nghẽn nằm ở đâu, việc phối hợp bớt phụ thuộc vào hỏi lại, nhắc việc và cập nhật thủ công.

Quy trình phối hợp phải quy định rõ điểm bàn giao

Một chương trình chuyển đổi số thường đi qua nhiều bộ phận theo chuỗi: tiếp nhận nhu cầu, đánh giá, ưu tiên, thiết kế, phê duyệt, cấu hình hoặc phát triển, kiểm thử, triển khai, vận hành và đo kết quả. Nếu mỗi điểm chuyển giao chỉ được hiểu ngầm, công việc dễ rơi vào khoảng trống giữa hai phòng ban.

Mỗi điểm bàn giao nên có ba yếu tố: đầu vào tối thiểu, người nhận chịu trách nhiệm và điều kiện hoàn tất. Chẳng hạn, một yêu cầu chỉ được chuyển từ nghiệp vụ sang IT khi đã có mục tiêu, phạm vi, quy tắc nghiệp vụ và người phê duyệt; ngược lại, IT chỉ bàn giao để nghiệm thu khi đã đáp ứng tiêu chí kiểm thử và có tài liệu vận hành cần thiết. Cách này biến phối hợp từ “gửi việc” thành một giao dịch có điều kiện rõ ràng.

Thời gian xử lý ở các điểm chờ cũng nên được đo. Tổ chức có thể đặt SLA nội bộ cho phê duyệt hoặc phản hồi, nhưng không nên áp một ngưỡng chung cho mọi quy trình. Hợp lý hơn là lấy thời gian hiện tại làm baseline, xác định điểm chờ nào tạo ra phần lớn cycle time rồi đặt mục tiêu cải thiện cho chính điểm đó. Ví dụ, nếu một bước phê duyệt đang mất trung bình ba ngày do phải chuyển qua nhiều cấp, mục tiêu rút xuống một ngày chỉ có ý nghĩa khi quyền phê duyệt và thông tin đầu vào cũng được thiết kế lại.

Xung đột phải có đường xử lý theo thẩm quyền

Trong triển khai liên phòng ban, xung đột không phải ngoại lệ hiếm gặp. Nó thường xuất hiện ở bốn nhóm: ưu tiên, nguồn lực, dữ liệu và mức chấp nhận rủi ro. Cơ chế phối hợp vì thế cần quy định trước vấn đề nào nhóm thực thi tự xử lý, vấn đề nào chủ sở hữu quy trình được quyền chốt và trường hợp nào phải đưa lên người bảo trợ hoặc ban điều phối.

Đường xử lý leo thang tốt không dựa vào chức danh cao nhất, mà dựa vào loại quyết định. Tranh luận về cách cấu hình trong phạm vi đã duyệt có thể giải quyết ở nhóm thực thi; mâu thuẫn giữa hai bộ phận về chủ sở hữu dữ liệu hoặc thứ tự ưu tiên nên được chủ sở hữu quy trình xử lý; thay đổi ngân sách, mục tiêu chương trình hoặc mức rủi ro chấp nhận được mới cần cấp bảo trợ. Nhờ vậy, lãnh đạo không bị kéo vào các quyết định tác nghiệp, còn nhóm triển khai không phải tự xử lý những vấn đề vượt thẩm quyền.

Sau khi vấn đề được đưa lên cấp có thẩm quyền, quyết định cần quay lại decision log và được truyền xuống các bên bị ảnh hưởng. Nếu chỉ “chốt trong cuộc họp” mà không cập nhật nguồn trạng thái chung, cùng một xung đột có thể xuất hiện lại ở vòng triển khai tiếp theo.

Hiệu quả phối hợp phải được đo trên kết quả xuyên quy trình

Đo riêng hiệu suất từng phòng ban có thể tạo ra tối ưu cục bộ. Một bộ phận hoàn thành phần việc của mình đúng hạn nhưng chuyển sang bộ phận sau với dữ liệu thiếu, lỗi nhiều hoặc yêu cầu chưa rõ thì toàn bộ quy trình vẫn chậm. Vì vậy, KPI phối hợp nên tập trung vào dòng công việc từ đầu đến cuối.

Các chỉ số hữu ích thường gồm cycle time toàn quy trình, thời gian chờ ở các điểm bàn giao, tỷ lệ bàn giao đúng hạn, tỷ lệ phải làm lại, số vấn đề phải đưa lên cấp cao hơn, thời gian xử lý vướng mắc và mức độ đạt kết quả nghiệp vụ sau triển khai. Với thay đổi có tác động tới người dùng, có thể bổ sung tỷ lệ áp dụng quy trình mới hoặc mức sử dụng tính năng liên quan.

Không có một benchmark duy nhất phù hợp cho mọi tổ chức. Cách đo đáng tin cậy hơn là thiết lập baseline trước khi thay đổi, chọn một số ít chỉ số phản ánh đúng điểm nghẽn và theo dõi xu hướng sau từng chu kỳ. Nếu cycle time giảm nhưng tỷ lệ làm lại tăng, cơ chế phối hợp đang đẩy nhanh bàn giao hơn là cải thiện chất lượng. Đây là lý do KPI phải được xem theo nhóm, không dùng một chỉ số đơn lẻ để kết luận.

Mức độ quản trị phải phù hợp với quy mô và độ phụ thuộc

Cơ chế phối hợp càng nhiều lớp không đồng nghĩa với quản trị càng tốt. Với một sáng kiến nhỏ, ít phòng ban và rủi ro thấp, một nhóm liên chức năng có chủ sở hữu quy trình rõ ràng, backlog chung và nhịp rà soát định kỳ thường hiệu quả hơn việc lập nhiều hội đồng. Khi chương trình mở rộng sang nhiều quy trình, nhiều đơn vị hoặc có phụ thuộc dữ liệu và công nghệ phức tạp, tổ chức mới cần lớp điều phối tập trung để giữ ưu tiên, kiến trúc, nguồn lực và quyết định nhất quán.

Trade-off cốt lõi nằm giữa tốc độ và kiểm soát. Quá ít quy tắc làm quyết định phụ thuộc vào quan hệ cá nhân và dễ mất dấu trách nhiệm; quá nhiều cổng phê duyệt làm tăng thời gian chờ. Thiết kế phù hợp là giữ những điểm kiểm soát gắn với rủi ro hoặc quyết định không thể đảo ngược, còn các quyết định tác nghiệp lặp lại nên được ủy quyền cho chủ sở hữu quy trình và nhóm thực thi.

Do đó, khi rà soát cơ chế phối hợp triển khai chuyển đổi số, câu hỏi thực tế không phải “đã có bao nhiêu cuộc họp hay ban chỉ đạo”, mà là “mỗi phụ thuộc giữa các phòng ban đã có chủ sở hữu, điểm bàn giao, quyền quyết định, nguồn thông tin và đường xử lý ngoại lệ hay chưa”. Nếu năm yếu tố này rõ, cơ chế có thể vận hành gọn mà vẫn kiểm soát được.

Phối hợp triển khai chuyển đổi số được tổ chức hiệu quả khi trách nhiệm đi theo quy trình xuyên phòng ban và mọi phụ thuộc đều có cơ chế xử lý rõ ràng. Cấp bảo trợ giữ quyền với mục tiêu, nguồn lực và rủi ro; chủ sở hữu quy trình chịu trách nhiệm cho kết quả đầu-cuối; nhóm liên chức năng thực thi trong phạm vi được ủy quyền. Luồng thông tin dùng nguồn trạng thái chung, điểm bàn giao có điều kiện hoàn tất, xung đột có đường xử lý leo thang và hiệu quả được đo bằng KPI xuyên quy trình. Cấu trúc cụ thể có thể khác nhau theo quy mô, nhưng nguyên tắc cốt lõi là không để trách nhiệm, thông tin hoặc quyết định rơi vào khoảng trống giữa các bộ phận.