Chuyển mục tiêu chuyển đổi số thành phạm vi, sản phẩm bàn giao và kết quả dự án.

Một mục tiêu có thể dẫn đến nhiều phạm vi khác nhau

“Nâng cao trải nghiệm khách hàng” có thể dẫn đến dự án đặt lịch, cập nhật trạng thái đơn hàng hoặc xử lý khiếu nại. Nếu chưa xác định vấn đề ưu tiên, đội triển khai có thể bàn giao một hệ thống nhiều chức năng nhưng không giải quyết đúng điểm khó chịu của khách hàng. Chuyển mục tiêu thành dự án vì vậy bắt đầu bằng việc làm rõ thay đổi cần đạt, trước khi chọn danh sách chức năng.

Mục tiêu chiến lược thường rộng và có thời gian dài hơn dự án. Phạm vi dự án là phần cam kết cụ thể trong bối cảnh nguồn lực, điều kiện và quyền hạn đã xác định. Không nên yêu cầu một dự án nhận trách nhiệm cho toàn bộ mục tiêu mà nó chỉ đóng góp một phần; cũng không nên tách sản phẩm bàn giao khỏi lý do kinh doanh.

Người quản lý dự án cần tạo đường nối giữa mục tiêu, kết quả, sản phẩm và công việc. Đường nối này giúp nhà bảo trợ hiểu đầu tư sẽ tạo điều kiện gì, chủ nghiệp vụ hiểu việc phải thay đổi và đội kỹ thuật biết cần xây gì. Năng lực xác định phạm vi trong chương trình quản lý dự án IT hỗ trợ biến mong muốn thành cam kết có thể kiểm tra.

Diễn đạt kết quả bằng thay đổi công việc

Hãy mô tả trạng thái tương lai bằng nhiệm vụ, người sử dụng và điều kiện. Thay cho “có nền tảng chăm sóc khách hàng”, có thể xác định “nhân viên tiếp nhận nhìn được lịch sử yêu cầu đúng quyền để xử lý hoặc chuyển tuyến theo quy tắc thống nhất”. Cách viết này cho biết khả năng cần tạo và hành vi cần kiểm chứng.

Kết quả phải có ranh giới. Nhóm khách hàng nào, loại yêu cầu nào và đơn vị nào được áp dụng trong giai đoạn này? Kết quả trong một chi nhánh không mặc nhiên bao gồm toàn bộ mạng lưới. Nếu có mục tiêu định lượng, cần đường cơ sở, nguồn dữ liệu, phương pháp tính và người xác nhận trước khi đưa vào hồ sơ cam kết.

Không gắn mức cải thiện khi chưa có dữ liệu hoặc đánh giá tính khả thi. Có thể ghi mục tiêu dự kiến cùng giả định và thời điểm xác nhận lại, rồi dùng bước khảo sát để hoàn thiện. Một mục tiêu được sửa theo bằng chứng đáng tin hơn con số chắc chắn nhưng không có cơ sở.

Xác định sản phẩm cần thiết để kết quả xảy ra

Sản phẩm bàn giao thường vượt quá phần mềm. Với quản lý yêu cầu khách hàng, dự án có thể cần luồng xử lý được phê duyệt, mô hình dữ liệu, phân quyền, tích hợp, tài liệu hướng dẫn, đào tạo và cơ chế hỗ trợ. Mỗi sản phẩm tạo một điều kiện cho công việc tương lai; thiếu một điều kiện có thể làm cả luồng không hoạt động.

Hãy phân rã sản phẩm theo khả năng nghiệm thu, không theo danh sách thao tác của đội triển khai. “Họp thống nhất quy trình” là hoạt động; “quy trình được chủ nghiệp vụ phê duyệt, có ngoại lệ và trách nhiệm” là sản phẩm. Lịch dự án sau đó mới xác định hoạt động cần làm để tạo sản phẩm ấy.

Liên kết từng sản phẩm với kết quả mà nó hỗ trợ. Nếu không giải thích được sản phẩm đóng góp gì, cần xem lại lý do đưa vào phạm vi. Ngược lại, nếu một kết quả không có sản phẩm hoặc công việc tạo điều kiện, đó là khoảng trống của kế hoạch. Cách nhìn này giúp tránh cả thêm việc thiếu giá trị lẫn bỏ sót việc nền.

Bảng chuyển mục tiêu thành cam kết

APM xem phạm vi trong mối liên hệ với đầu ra, kết quả, lợi ích và công việc tạo ra chúng. Trong thực hành, bảng này nên được xây cùng chủ nghiệp vụ, IT và người nhận vận hành. Các bên cần đọc được quan hệ giữa từng lớp, thay vì chỉ đồng ý riêng lẻ với những danh sách không nối nhau.

Ghi rõ ranh giới và giao diện giữa các phần

Phạm vi cần nói rõ phần bao gồm và loại trừ. Nếu dự án chuẩn hóa tiếp nhận yêu cầu nhưng không thay đổi chính sách bồi hoàn, hãy ghi điều đó và xác định cách giao tiếp với quy trình bồi hoàn hiện hữu. Phần loại trừ không làm biến mất một phụ thuộc cần thiết cho kết quả chung.

Với hệ thống kết nối, chỉ rõ ai cung cấp dữ liệu, ai chịu trách nhiệm chất lượng và ai xác nhận kết quả trao đổi. Nếu tích hợp phụ thuộc dự án khác, phải có chủ phối hợp và điều kiện bàn giao. Đừng để một dòng “tích hợp sẵn có” thay thế việc xác nhận thực tế về thời gian và năng lực.

Ranh giới địa lý, nhóm người dùng, loại giao dịch và dữ liệu cần nhất quán giữa hồ sơ phạm vi, hợp đồng và kế hoạch. Khi tài liệu dùng các cách gọi khác nhau, cần làm rõ trước triển khai. Tư duy phối hợp trong chương trình chuyển đổi số giúp xử lý ranh giới giữa công nghệ với hoạt động các phòng ban.

Viết tiêu chí chấp nhận trước khi tạo sản phẩm

Tiêu chí nên mô tả điều kiện kiểm tra và kết quả mong đợi. Với chức năng chuyển yêu cầu, cần xác định người thực hiện, loại yêu cầu, thông tin bắt buộc, nơi nhận, quyền xem và cách ghi lịch sử. “Chức năng hoạt động tốt” không cung cấp đủ căn cứ để nghiệm thu hoặc xử lý bất đồng.

Phân biệt tiêu chí sản phẩm với chỉ số lợi ích. Dữ liệu được chuyển đúng quy tắc có thể được nghiệm thu trước go-live; thời gian xử lý được cải thiện cần quan sát sau khi công việc mới vận hành. Cả hai cần kế hoạch và chủ xác nhận nhưng không nên dùng thay thế cho nhau.

Những yêu cầu về hiệu năng, bảo mật, hỗ trợ và khả năng phục hồi cũng cần tiêu chí phù hợp với phạm vi. Các bên chuyên môn phải được tham gia xác định, thay vì chờ cuối dự án mới phát hiện điều kiện vận hành. Nội dung của chuyên đề triển khai hệ thống IT giúp kết nối sản phẩm với sự sẵn sàng thực tế.

Phân kỳ khi mục tiêu vượt khả năng một dự án

Không phải mọi khả năng đều phải triển khai cùng lúc. Có thể chọn một luồng công việc đầu cuối đủ tạo giá trị và học hỏi, rồi bổ sung các phạm vi sau theo điều kiện. Phân kỳ theo nhóm chức năng rời rạc dễ tạo hệ thống có nhiều mảnh nhưng chưa có nhiệm vụ nào hoàn tất được.

Xác định rõ kết quả của từng giai đoạn và những khả năng còn thiếu. Nếu giai đoạn đầu chỉ tạo dữ liệu đáng tin, hãy giải thích nó chuẩn bị cho quyết định gì và ai nhận quản lý. Tránh gọi mọi sản phẩm nền là lợi ích đã thực hiện, nhưng cũng không loại bỏ chúng chỉ vì chưa tạo kết quả tài chính ngay.

Nguồn lực cần tính cả chủ nghiệp vụ, người kiểm thử và đội hỗ trợ. Khi các vai trò này bị quá tải, việc giảm số phạm vi đồng thời có thể hợp lý hơn rút ngắn thời gian xác nhận. Phân kỳ tốt giúp giới hạn cam kết và bảo vệ chất lượng của mỗi bước.

Tình huống giả định: Mục tiêu minh bạch đơn hàng

Một doanh nghiệp giả định đặt mục tiêu giúp khách hàng biết đơn hàng đang ở đâu. Đề xuất ban đầu là xây cổng thông tin với nhiều trang báo cáo. Qua khảo sát, đội dự án nhận thấy trạng thái giao hàng giữa kho và vận chuyển chưa có định nghĩa thống nhất, nên cổng mới có thể hiển thị thông tin không đáng tin.

Nhà bảo trợ cùng chủ nghiệp vụ chuyển mục tiêu thành kết quả cụ thể: nhân viên có thể xác nhận trạng thái của một nhóm đơn hàng trong phạm vi thí điểm theo quy tắc chung. Phạm vi gồm định nghĩa trạng thái, cập nhật trách nhiệm, dữ liệu nguồn, tích hợp và màn hình tra cứu; các báo cáo nâng cao được để ở giai đoạn sau.

Tiêu chí nghiệm thu kiểm tra cả luồng cập nhật và quyền xem, còn lợi ích được đánh giá qua khả năng trả lời yêu cầu khách hàng. Doanh nghiệp chỉ quyết định mở cổng cho khách hàng khi dữ liệu đủ tin cậy. Bài học là sản phẩm phù hợp phải được chọn từ chuỗi điều kiện của kết quả, không từ độ hấp dẫn của giao diện.

Giữ đường nối khi yêu cầu thay đổi

Mỗi đề nghị mới cần chỉ rõ kết quả liên quan, sản phẩm bị ảnh hưởng và tác động tới công việc, thời gian, chi phí hoặc rủi ro. Một chức năng nhỏ về giao diện có thể làm tăng yêu cầu dữ liệu hay kiểm thử; đánh giá tác động không nên chỉ dựa vào thời gian lập trình.

Quyết định chấp nhận, hoãn hoặc từ chối phải được ghi lại cùng lý do. Khi thay đổi làm giảm khả năng đạt mục tiêu, nhà bảo trợ cần chốt lại ưu tiên và cam kết. Cơ chế từ chuyên đề quản lý thay đổi IT hỗ trợ kiểm soát đường cơ sở mà vẫn cho phép cập nhật theo hiểu biết mới.

• Mục tiêu có vấn đề và phạm vi đo rõ không?
• Kết quả có mô tả công việc của người sử dụng không?
• Mỗi sản phẩm có tiêu chí chấp nhận và người xác nhận không?
• Phần loại trừ có phụ thuộc cần quản lý không?
• Sau bàn giao, ai chịu trách nhiệm đo và duy trì lợi ích?

Để bắt đầu, chọn một mục tiêu ưu tiên và cùng các bên xây một trang thể hiện năm lớp trong bảng trên. Khi quan hệ giữa chúng rõ ràng, đội dự án mới có cơ sở phân rã công việc và cam kết kế hoạch. Phạm vi lúc đó trở thành lời giải có thể kiểm chứng cho mục tiêu kinh doanh.

Bài viết liên quan

• Dự án chuyển đổi số đúng tiến độ nhưng doanh nghiệp không thay đổi: Vì sao?
• Xây dựng Project Charter cho dự án chuyển đổi số: Những nội dung không thể bỏ qua.
• Đánh giá hiện trạng quy trình AS-IS và thiết kế quy trình TO-BE trước khi triển khai giải pháp.
• Quản lý yêu cầu nghiệp vụ: Làm thế nào để IT hiểu đúng vấn đề của các phòng ban?

Nguồn tham khảo

1. APM – What is scope management?
2. APM – Benefits management and project success
3. APM – What is a business case?