Cách phân công trách nhiệm triển khai công nghệ

Điểm quan trọng là tách người thực hiện công việc khỏi người chịu trách nhiệm cuối cùng cho kết quả. Nhiều bộ phận có thể cùng tham gia triển khai, nhưng với mỗi quyết định hoặc đầu ra quan trọng, doanh nghiệp nên xác định rõ một đầu mối chịu trách nhiệm điều phối và một cấp có thẩm quyền phê duyệt. Cách phân công này giảm tình trạng “nhiều người cùng phụ trách nhưng không ai thực sự chịu trách nhiệm”.

Phân công theo đầu ra và quyền quyết định thay vì chỉ theo phòng ban

Trách nhiệm triển khai công nghệ rõ nhất khi doanh nghiệp bắt đầu từ câu hỏi: đầu ra nào phải được tạo ra, ai làm, ai quyết định và ai xác nhận đầu ra đã đạt yêu cầu?

Một hạng mục triển khai thường cần tối thiểu bốn vai trò:

·         Chủ trì: Điều phối công việc, theo dõi tiến độ và chịu trách nhiệm đưa hạng mục đến trạng thái hoàn thành

·         Phối hợp: Cung cấp chuyên môn, dữ liệu, nguồn lực hoặc thực hiện phần việc thuộc phạm vi của mình

·         Phê duyệt: Có quyền chấp thuận hoặc từ chối một quyết định, phương án hay đầu ra

·         Tiếp nhận: Xác nhận đầu ra đáp ứng điều kiện để đưa vào sử dụng hoặc vận hành

Ví dụ, khi triển khai hệ thống quản lý khách hàng, bộ phận công nghệ có thể chủ trì cấu hình và tích hợp kỹ thuật, kinh doanh chịu trách nhiệm xác định quy trình nghiệp vụ, an toàn thông tin đánh giá quyền truy cập, còn lãnh đạo có thẩm quyền phê duyệt phạm vi và ngân sách.

Nếu chỉ ghi “IT phụ trách hệ thống CRM”, phần trách nhiệm vẫn chưa đủ rõ. IT có thể triển khai kỹ thuật nhưng không nên tự quyết định quy trình bán hàng, tiêu chuẩn dữ liệu khách hàng hay điều kiện nghiệm thu nghiệp vụ nếu các quyết định này thuộc đơn vị sử dụng.

Một nguyên tắc thực tế là: mỗi đầu ra quan trọng nên có một đầu mối chịu trách nhiệm chính, nhưng có thể có nhiều bên phối hợp. Nếu có hai đơn vị cùng được ghi là “chịu trách nhiệm chính” mà không xác định quyền quyết định cuối cùng, xung đột thường xuất hiện khi tiến độ, chi phí hoặc yêu cầu thay đổi.

Xác định trách nhiệm từ các lớp quản trị đến thực thi

Một dự án công nghệ thường đi qua nhiều lớp trách nhiệm. Việc tách các lớp này giúp doanh nghiệp tránh giao cả quyền yêu cầu, thực hiện, kiểm tra và phê duyệt cho cùng một bên khi không phù hợp.

Lãnh đạo bảo trợ chịu trách nhiệm về mục tiêu và nguồn lực

Sponsor hoặc lãnh đạo bảo trợ xác lập mục tiêu kinh doanh, phạm vi ưu tiên và nguồn lực cho chương trình công nghệ. Vai trò này tập trung vào các quyết định có ảnh hưởng lớn như ngân sách, thay đổi phạm vi, xung đột giữa đơn vị hoặc chấp nhận rủi ro vượt thẩm quyền của nhóm dự án.

Sponsor không cần điều hành từng nhiệm vụ kỹ thuật. Nếu lãnh đạo phải trực tiếp giải quyết các công việc vận hành hàng ngày, ranh giới giữa quản trị và thực thi đã bị thu hẹp quá mức.

Đơn vị nghiệp vụ chịu trách nhiệm về yêu cầu và kết quả sử dụng

Business Owner hoặc Process Owner phải xác định công nghệ cần giải quyết vấn đề nào, quy trình nào cần thay đổi và điều kiện nào chứng minh giải pháp có thể sử dụng.

Bộ phận công nghệ có thể tư vấn phương án, nhưng không thể thay đơn vị nghiệp vụ xác nhận rằng một quy trình mới thực sự phù hợp với hoạt động kinh doanh. Khi trách nhiệm này bị chuyển hoàn toàn sang IT, hệ thống có thể hoàn thành về kỹ thuật nhưng vẫn thất bại khi đưa vào sử dụng.

Đơn vị công nghệ chịu trách nhiệm về thiết kế và triển khai kỹ thuật

Technology Lead hoặc đội công nghệ chịu trách nhiệm về kiến trúc, cấu hình, tích hợp, môi trường kỹ thuật, xử lý lỗi và khả năng vận hành của giải pháp trong phạm vi được giao.

Trách nhiệm kỹ thuật cần đi cùng giới hạn rõ ràng. IT không mặc nhiên chịu trách nhiệm cho chất lượng dữ liệu nguồn, mức độ chấp nhận của người dùng hoặc quyết định nghiệp vụ nếu những yếu tố này nằm ngoài quyền kiểm soát của IT.

Các chức năng kiểm soát chịu trách nhiệm trong phạm vi chuyên môn

An toàn thông tin, dữ liệu, pháp chế, tài chính, kiểm toán hoặc quản trị rủi ro tham gia khi dự án có yêu cầu tương ứng.

Họ không nhất thiết trở thành đồng chủ trì toàn bộ dự án. Trách nhiệm nên giới hạn vào các quyết định thuộc chuyên môn, chẳng hạn kiểm soát truy cập, yêu cầu bảo vệ dữ liệu, điều kiện hợp đồng hoặc chấp nhận một loại rủi ro cụ thể.

Gắn từng trách nhiệm với đầu ra và tiêu chí nghiệm thu

Tên vai trò chỉ trả lời được “ai tham gia”. Để trách nhiệm có thể kiểm soát được, doanh nghiệp còn phải xác định người đó phải tạo ra hoặc xác nhận điều gì.

Mỗi nhiệm vụ quan trọng nên có ít nhất:

·         Đầu ra: Tài liệu yêu cầu, thiết kế, cấu hình, dữ liệu đã chuyển đổi, kết quả kiểm thử, hướng dẫn vận hành hoặc sản phẩm tương đương

·         Người chủ trì: Cá nhân hoặc vai trò chịu trách nhiệm điều phối để đầu ra được hoàn thành

·         Bên phối hợp: Những đơn vị phải cung cấp thông tin, chuyên môn hoặc thực hiện phần việc phụ thuộc

·         Người phê duyệt: Cấp có quyền chấp thuận đầu ra hoặc quyết định

·         Thời hạn: Mốc mà đầu ra phải sẵn sàng

·         Tiêu chí nghiệm thu: Điều kiện cụ thể để xác định hoàn thành

·         Điểm phụ thuộc: Dữ liệu, quyết định hoặc đầu ra khác phải có trước

·         Cơ chế escalation: Người xử lý khi nhiệm vụ bị chậm, có xung đột hoặc vượt thẩm quyền

Ví dụ, nhiệm vụ “kiểm thử chấp nhận người dùng” chưa đủ rõ nếu chỉ giao cho phòng kinh doanh. Trách nhiệm có thể được mô tả cụ thể hơn: đơn vị nghiệp vụ chủ trì thực hiện các kịch bản đã thống nhất, IT xử lý lỗi kỹ thuật, quản lý nghiệp vụ phê duyệt kết quả và chỉ cho phép chuyển sang vận hành khi các lỗi nghiêm trọng thuộc phạm vi nghiệm thu đã được xử lý hoặc được chấp nhận theo thẩm quyền.

Cách mô tả này khiến trạng thái hoàn thành có thể kiểm chứng thay vì phụ thuộc vào nhận định “đã làm xong”.

Tách trách nhiệm thực hiện, phối hợp và phê duyệt tại các điểm quyết định

Không phải mọi công việc đều cần cấp quản lý phê duyệt. Phê duyệt nên tập trung tại những điểm mà quyết định có thể thay đổi đáng kể phạm vi, chi phí, rủi ro hoặc khả năng vận hành.

Các điểm thường cần xác định thẩm quyền gồm:

1.    Phê duyệt yêu cầu và phạm vi: Xác nhận doanh nghiệp đang giải quyết đúng vấn đề

2.    Phê duyệt phương án: Chấp thuận lựa chọn có ảnh hưởng lớn đến kiến trúc, chi phí hoặc cách vận hành

3.    Phê duyệt thay đổi: Quyết định khi phát sinh yêu cầu ngoài phạm vi ban đầu

4.    Phê duyệt nghiệm thu: Xác nhận đầu ra đáp ứng yêu cầu đã thống nhất

5.    Phê duyệt đưa vào vận hành: Chấp nhận các điều kiện còn tồn tại trước khi hệ thống chính thức được sử dụng

Một lỗi phổ biến là yêu cầu quá nhiều người cùng phê duyệt mọi quyết định. Cách này tạo cảm giác kiểm soát nhưng có thể làm chậm tiến độ và khiến trách nhiệm bị phân tán.

Ở chiều ngược lại, trao toàn bộ quyền quyết định cho nhóm triển khai cũng tạo rủi ro. Nhóm kỹ thuật có thể quyết định tốt về kỹ thuật nhưng không có thẩm quyền chấp nhận thay đổi ngân sách, rủi ro kinh doanh hoặc yêu cầu nghiệp vụ.

Doanh nghiệp vì vậy cần xác định decision right theo từng loại quyết định: vấn đề nào nhóm dự án tự xử lý, vấn đề nào Product/Business Owner quyết định và ngưỡng nào phải chuyển lên Sponsor hoặc cấp quản lý cao hơn.

Quản lý trách nhiệm giữa các phòng ban và nhà cung cấp

Các điểm giao giữa nhiều bên thường là nơi trách nhiệm dễ bị bỏ trống nhất. Một công việc có thể bị đình trệ không phải vì không có người làm, mà vì một bên đang chờ đầu vào mà bên còn lại không biết mình phải cung cấp.

Doanh nghiệp nên ghi rõ các dependency quan trọng. Chẳng hạn:

·         IT chỉ bắt đầu chuyển đổi dữ liệu khi đơn vị nghiệp vụ đã xác nhận quy tắc làm sạch dữ liệu

·         Nhà cung cấp chỉ cấu hình một chức năng sau khi Product Owner phê duyệt yêu cầu

·         Bộ phận an toàn thông tin chỉ đánh giá chính thức khi kiến trúc và mô hình phân quyền đủ thông tin

·         Nhóm vận hành chỉ tiếp nhận khi tài liệu, quyền quản trị, quy trình xử lý sự cố và các điều kiện bàn giao đã hoàn tất

Đối với nhà cung cấp, hợp đồng có thể giao trách nhiệm thực hiện một phần đáng kể của dự án nhưng không thay thế trách nhiệm quản trị nội bộ.

Nhà cung cấp có thể chịu trách nhiệm cấu hình, phát triển hoặc hỗ trợ triển khai. Doanh nghiệp vẫn cần người nội bộ chịu trách nhiệm về yêu cầu, quyết định chấp nhận đầu ra, quyền truy cập, rủi ro và khả năng vận hành sau khi hợp đồng kết thúc.

Doanh nghiệp nhỏ có thể để một người kiêm nhiều vai trò. Việc kiêm nhiệm không nhất thiết tạo vấn đề nếu từng “chiếc mũ” vẫn có quyền và đầu ra được xác định rõ. Điều cần tránh là vì cùng một người đảm nhiệm nhiều vai trò nên bỏ luôn bước kiểm tra hoặc không xác định lúc nào người đó đang thực hiện, lúc nào đang phê duyệt.

Theo dõi trách nhiệm bằng ma trận và các điểm kiểm soát

Ma trận trách nhiệm như RACI có thể được sử dụng để thể hiện ai thực hiện, ai chịu trách nhiệm cuối cùng, ai cần được tham vấn và ai cần được thông báo. Tuy nhiên, ma trận chỉ có giá trị khi gắn với công việc hoặc đầu ra cụ thể.

Một bảng ghi “Kinh doanh – IT – Tài chính – Nhà cung cấp” theo tên phòng ban nhưng không gắn với deliverable vẫn khó sử dụng để điều hành.

Doanh nghiệp nên lập ma trận ở mức đủ chi tiết cho các đầu ra trọng yếu, chẳng hạn:

·         Yêu cầu nghiệp vụ

·         Thiết kế giải pháp

·         Kiến trúc và tích hợp

·         Chuẩn bị dữ liệu

·         Kiểm thử kỹ thuật

·         Kiểm thử nghiệp vụ

·         Đánh giá bảo mật

·         Đào tạo người dùng

·         Phê duyệt go-live

·         Bàn giao vận hành

Ma trận này cần được kiểm tra lại khi phạm vi, nhân sự hoặc cách triển khai thay đổi. Một trách nhiệm đúng ở giai đoạn thiết kế có thể không còn đúng khi dự án chuyển sang vận hành.

Các cuộc họp tiến độ cũng nên xoay quanh đầu ra và quyết định thay vì chỉ hỏi tỷ lệ hoàn thành. Với mỗi hạng mục chưa đạt, nhóm dự án cần biết ngay: đầu ra còn thiếu gì, đang chờ ai, ai có quyền quyết định và khi nào vấn đề phải được escalation.

Hoàn tất trách nhiệm bằng bàn giao và trách nhiệm vận hành

Trách nhiệm triển khai không kết thúc tại thời điểm hệ thống được bật lên. Nếu không xác định người tiếp nhận sau go-live, trách nhiệm có thể rơi vào khoảng trống giữa dự án và vận hành.

Trước khi bàn giao, doanh nghiệp nên làm rõ:

·         Ai sở hữu hệ thống hoặc sản phẩm sau triển khai

·         Ai quản trị tài khoản, cấu hình và quyền truy cập

·         Ai theo dõi sự cố và hiệu năng vận hành

·         Ai tiếp nhận yêu cầu thay đổi

·         Ai quản lý nhà cung cấp và hợp đồng hỗ trợ

·         Ai chịu trách nhiệm về dữ liệu

·         Ai quyết định ưu tiên cải tiến tiếp theo

·         Điều kiện nào phải đạt trước khi đội dự án được giải phóng trách nhiệm

Nếu các trách nhiệm vận hành chưa được tiếp nhận, việc tuyên bố dự án “hoàn thành” chỉ phản ánh tiến độ triển khai, chưa phản ánh khả năng duy trì kết quả.

Một cơ chế phân công tốt vì vậy tạo được chuỗi trách nhiệm liên tục: từ người xác định nhu cầu, người thực hiện, người kiểm soát, người phê duyệt đến người tiếp nhận và vận hành.

Doanh nghiệp nên phân công trách nhiệm triển khai công nghệ dựa trên đầu ra, quyền quyết định và tiêu chí nghiệm thu, thay vì chỉ ghi tên phòng ban phụ trách. Với mỗi hạng mục quan trọng, cần xác định rõ ai chủ trì, ai phối hợp, ai phê duyệt, đầu ra phải đạt điều kiện gì và vấn đề sẽ được chuyển cho ai khi vượt thẩm quyền.

Cách phân công này vẫn áp dụng được khi tổ chức nhỏ, nhiều người kiêm nhiệm hoặc có nhà cung cấp bên ngoài. Vai trò có thể được gộp, nhưng quyền quyết định, trách nhiệm đối với đầu ra và cơ chế bàn giao không nên trở nên mơ hồ.