INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Bàn giao đúng hạn chưa đủ: Giám đốc dự án IT cần tạo giá trị kinh doanh

Ngày bàn giao xác nhận sản phẩm đã hoàn tất, nhưng lợi ích còn phụ thuộc vào cách doanh nghiệp sử dụng. Giám đốc dự án cần nối phạm vi, trách nhiệm nghiệp vụ và bằng chứng sau triển khai để khoản đầu tư tạo ra thay đổi có thể kiểm chứng.

Biên soạn: Infochief Academy · Chuyên đề: Giám đốc dự án IT – Project Manager

← Trở về thư viện bài viết

Minh họa biên tập: giám đốc dự án trao đổi với quản lý nghiệp vụ và tài chính về kết quả kinh doanh của dự án IT.

Một dự án có thể khép lại bằng biên bản nghiệm thu rất đẹp: đủ chức năng, đúng lịch, chi phí trong giới hạn. Nhưng vài tháng sau, người dùng vẫn nhập dữ liệu hai lần, quản lý vẫn chờ báo cáo thủ công và bộ phận vận hành chưa giảm được khối lượng xử lý. Trong tình huống giả định ấy, đội dự án hoàn thành điều đã cam kết, còn doanh nghiệp chưa nhận được điều từng kỳ vọng.

Khoảng cách bắt đầu từ cách định nghĩa thành công. Nếu mục tiêu chỉ là đưa phần mềm vào sử dụng, mọi quyết định sẽ hướng về ngày bàn giao. Nếu mục tiêu là rút ngắn một công đoạn kinh doanh, dự án phải quan tâm cả cách nhân viên làm việc, chất lượng dữ liệu và người chịu trách nhiệm giữ kết quả sau triển khai.

Giám đốc dự án IT không thể một mình bảo đảm doanh thu hay năng suất. Tuy nhiên, họ có thể tạo ra một cơ chế để sản phẩm được chuyển thành thay đổi vận hành, và thay đổi ấy được kiểm tra bằng bằng chứng. Đó là phần trách nhiệm cần nhìn thấy ngay từ đầu, thay vì bổ sung khi dự án đã kết thúc.

Ngày bàn giao chỉ xác nhận một lớp thành công

Sản phẩm bàn giao là thứ dự án tạo ra: hệ thống, tích hợp, dữ liệu chuyển đổi, tài liệu và năng lực sử dụng. Kết quả vận hành là điều xảy ra khi doanh nghiệp dùng những sản phẩm đó: đơn hàng được xác nhận nhanh hơn, lỗi được phát hiện sớm hơn hoặc quy trình có thể truy vết. Lợi ích là giá trị của thay đổi ấy đối với tổ chức. Ba lớp liên quan nhưng không đồng nhất.

Một cổng khách hàng được nghiệm thu chưa chứng minh khách hàng sẽ sử dụng. Số người đăng nhập cũng chưa cho biết họ hoàn tất giao dịch hay phải gọi điện nhờ nhân viên hỗ trợ. Vì vậy, khi lãnh đạo chỉ xem tiến độ xây dựng, tín hiệu về khả năng tạo lợi ích thường xuất hiện quá muộn. Dự án vẫn xanh trên báo cáo trong lúc cơ chế tạo giá trị đã bị suy yếu.

PMI trình bày quản lý lợi ích qua việc xác định, thực hiện và duy trì lợi ích sau khi công việc chuyển sang đơn vị kinh doanh. Cách nhìn này mở rộng thời gian quan sát mà không buộc đội dự án tồn tại vô hạn. Điều cần thiết là một kế hoạch chuyển giao trách nhiệm, cùng lịch đo kết quả và quyền xử lý khi lợi ích không xuất hiện.

Đối với người đang phát triển năng lực lãnh đạo dự án IT, câu hỏi quan trọng là: biên bản bàn giao xác nhận đã giao gì, và hồ sơ nào xác nhận doanh nghiệp đã đủ điều kiện khai thác? Khi hai câu hỏi được tách rõ, việc lập kế hoạch mới có thể bao quát cả sản phẩm lẫn cách dùng sản phẩm.

Nối mục tiêu với công việc bằng một chuỗi có thể kiểm tra

Hãy bắt đầu từ một kết quả nghiệp vụ cụ thể. Chẳng hạn, doanh nghiệp muốn giảm thời gian xác nhận đơn hàng. Nhóm dự án cần xác định thời gian đang mất ở đâu: kiểm tra tồn kho, đối chiếu hạn mức tín dụng hay chờ người duyệt. Một giải pháp tự động hóa sai công đoạn có thể tăng tốc hệ thống mà không rút ngắn thời gian khách hàng phải chờ.

Từ kết quả mong muốn, nhóm xác định năng lực cần có, hành vi cần thay đổi và điều kiện để thay đổi diễn ra. Nếu phần mềm trả kết quả kiểm tra tín dụng ngay nhưng quyền duyệt vẫn tập trung vào một người thường vắng mặt, lợi ích sẽ bị chặn ở tổ chức công việc. Phạm vi dự án lúc này cần bao gồm việc thống nhất quyền duyệt và cơ chế xử lý ngoại lệ, với chủ nghiệp vụ chịu trách nhiệm.

Bảng dưới đây là công cụ đề xuất để kiểm tra mối liên hệ ấy trước khi chốt phạm vi. Những minh chứng trong bảng cần được điều chỉnh theo quy trình thực tế, không dùng như chỉ tiêu chung cho mọi dự án.

Lớp cần kiểm tra	Câu hỏi quyết định	Minh chứng phù hợp
Mục tiêu nghiệp vụ	Cần cải thiện công đoạn nào?	Số liệu thời gian chờ hiện tại
Năng lực hệ thống	Chức năng nào xử lý nguyên nhân?	Kịch bản giao dịch đầu cuối
Thay đổi cách làm	Vai trò nào phải làm khác?	Quy trình và quyền đã thống nhất
Điều kiện vận hành	Ai xử lý trường hợp ngoại lệ?	Phân công và hướng dẫn xử lý
Lợi ích sau triển khai	Ai đo và giải thích kết quả?	Chủ lợi ích, nguồn dữ liệu, lịch đo

Giá trị của bảng nằm ở những khoảng trống. Một chức năng không nối được với mục tiêu có thể là phạm vi chưa cần thiết. Một lợi ích không có chủ trách nhiệm có thể là kỳ vọng chưa đủ cơ sở. Phát hiện trước khi đầu tư giúp lãnh đạo có thời gian đổi phương án, thay vì đòi đội dự án chứng minh giá trị bằng lời giải thích sau bàn giao.

Phân trách nhiệm để giá trị không trở thành lời hứa của IT

Sponsor, tức người bảo trợ dự án, cần giữ sự liên hệ giữa đầu tư và mục tiêu kinh doanh. Chủ nghiệp vụ chịu trách nhiệm về cách quy trình vận hành và điều kiện tạo lợi ích. Giám đốc dự án tổ chức công việc, đưa phụ thuộc vào kế hoạch và trình những quyết định vượt thẩm quyền. Bộ phận tài chính hỗ trợ kiểm tra cách tính, còn đơn vị vận hành tiếp nhận trách nhiệm duy trì.

Sự phân công phải thể hiện trong việc cụ thể. Người quản lý bán hàng có thể chịu trách nhiệm bố trí nhân viên thử quy trình mới; người quản lý dữ liệu phải giải quyết mã khách hàng trùng; đội IT phải chứng minh tích hợp hoạt động theo kịch bản. Nếu chỉ viết chung rằng các phòng ban phối hợp, những việc này sẽ không có người cam kết thời gian hoàn thành.

Việc phân quyền cũng cho thấy giới hạn của giám đốc dự án. Họ có trách nhiệm cảnh báo khi điều kiện tạo giá trị đang mất đi, nhưng không tự thay mục tiêu kinh doanh hoặc chấp nhận rủi ro ngoài ủy quyền. Các vấn đề ấy cần được đưa tới người quyết định, cùng phương án và tác động. Đây là nơi tư duy lãnh đạo công nghệ giúp kết nối trách nhiệm dự án với quyền điều hành doanh nghiệp.

Đo thay đổi từ đường cơ sở, không từ cảm nhận

Trước triển khai, cần biết quy trình đang hoạt động thế nào. Đường cơ sở có thể là thời gian trung vị xử lý, tỷ lệ giao dịch phải làm lại hoặc chi phí xử lý trên một nhóm giao dịch xác định. Khoảng thời gian đo, phạm vi dữ liệu và trường hợp loại trừ phải được ghi rõ. Nếu mỗi phòng ban dùng một cách tính, kết quả sau triển khai sẽ khó so sánh.

Sau triển khai, đo cùng định nghĩa và phân tích bối cảnh. Thời gian xác nhận đơn hàng giảm có thể do quy trình mới, nhưng cũng có thể do mùa thấp điểm hoặc thay đổi loại khách hàng. Không nên quy toàn bộ chênh lệch cho phần mềm. Có thể so sánh theo nhóm giao dịch tương đồng, theo dõi nhiều kỳ và bổ sung bằng chứng từ các bước xử lý đã được thay đổi.

Không phải lợi ích nào cũng cần quy thành tiền. Khả năng truy vết, chất lượng dữ liệu và mức độ kiểm soát có thể được trình bày bằng chỉ số phù hợp. Khi quy đổi tài chính, phải tách thời gian có thể tiết kiệm khỏi khoản chi thực sự giảm. Nhân viên bớt thao tác không tự động đồng nghĩa giảm chi phí nhân sự; tổ chức có thể dùng năng lực ấy để xử lý thêm công việc.

Cách đo này đòi hỏi dự án lập kế hoạch dữ liệu từ sớm. Ai trích xuất, ai kiểm tra và ai giải thích biến động đều cần được thống nhất. Với dự án làm thay đổi nhiều bộ phận, năng lực quản trị chuyển đổi số giúp đặt hoạt động đo vào chuỗi thay đổi nghiệp vụ, tránh xem đó là công việc báo cáo riêng của IT.

Đưa bằng chứng giá trị vào các quyết định triển khai

Không cần đợi đến khi đóng dự án mới hỏi lợi ích còn khả thi hay không. Trong giai đoạn thiết kế, kiểm tra giải pháp có xử lý đúng nguyên nhân. Trong kiểm thử, xác nhận người dùng hoàn thành được nhiệm vụ. Trước vận hành, kiểm tra dữ liệu, quyền, hỗ trợ và cơ chế ngoại lệ. Mỗi điểm kiểm tra phải dẫn tới một quyết định, thay vì chỉ bổ sung biểu mẫu.

Tình huống minh họa giả định: một doanh nghiệp triển khai hệ thống duyệt mua hàng nhằm giảm thời gian chờ. Kiểm thử chức năng đạt nhưng giao dịch bị dừng khi người duyệt đi công tác. Đội dự án có thể bổ sung cảnh báo; tuy nhiên, nếu quyền ủy quyền chưa được thống nhất, thông báo nhanh hơn vẫn không tạo ra quyết định nhanh hơn. Sponsor cần phối hợp với chủ quy trình chốt phương án ủy quyền trước khi mở rộng.

Khi đó, tiến độ được đánh giá lại theo hai lựa chọn: giữ ngày vận hành với phạm vi giới hạn và biện pháp bù đã kiểm tra, hoặc điều chỉnh lịch để hoàn thiện điều kiện. Không lựa chọn nào mặc nhiên đúng. Phân tích phải cho biết giao dịch nào bị ảnh hưởng, ai nhận trách nhiệm và lợi ích nào sẽ chậm. Kết quả kỳ vọng chỉ được xác nhận sau khi có số liệu vận hành.

Việc nối kiểm thử với mục tiêu nghiệp vụ thuộc nền tảng quản lý dự án CNTT. Ở cấp lãnh đạo, cần thêm khả năng bảo vệ những công việc tạo điều kiện cho giá trị, ngay cả khi chúng không làm báo cáo phần trăm hoàn thành trông đẹp hơn. Dữ liệu sạch và người dùng sẵn sàng thường quan trọng hơn một chức năng phụ được hoàn tất đúng hạn.

Bàn giao trách nhiệm cùng sản phẩm

Trước đóng dự án, giám đốc dự án cần cùng đơn vị tiếp nhận rà soát bốn việc: sản phẩm đã được chấp nhận, điều kiện vận hành đã đủ, tồn đọng đã có người xử lý và lợi ích đã có kế hoạch theo dõi. Một điểm còn mở không nhất thiết ngăn đóng dự án, nhưng phải được đánh giá tác động và chuyển giao bằng cam kết có thể kiểm tra.

Hồ sơ lợi ích nên ghi người sở hữu, định nghĩa chỉ số, đường cơ sở, thời điểm đo và điều kiện cần duy trì. Những giả định chưa được kiểm chứng phải được giữ lại, không xóa khỏi hồ sơ chỉ vì dự án đã qua nghiệm thu. Đơn vị kinh doanh cần biết khi nào phải trình cấp điều hành nếu kết quả không xuất hiện hoặc phát sinh tác động bất lợi.

Cuộc rà soát sau bàn giao cần nhìn cả thay đổi tích cực và chi phí mới. Quy trình nhanh hơn nhưng đội hỗ trợ phải can thiệp thường xuyên có thể chưa ổn định. Một chỉ số cải thiện nhưng người dùng chuyển phần việc khó sang ngoài hệ thống cũng cần xem lại. Giá trị bền vững đòi hỏi tổ chức nhận biết và xử lý những hiện tượng ấy.

Quay về dự án có biên bản nghiệm thu đẹp, câu hỏi cần bổ sung rất cụ thể: ai sẽ kiểm tra việc nhập dữ liệu hai lần đã được loại bỏ? Bắt đầu bằng một lợi ích quan trọng, nối nó với công đoạn thực tế và giao trách nhiệm theo dõi. Khi lãnh đạo dự án thiết kế được chuỗi này, ngày bàn giao trở thành một mốc có ý nghĩa trong quá trình tạo giá trị.