INFOCHIEF ACADEMY · PROJECT MANAGER KNOWLEDGE SERIES

Xây dựng Business Case để đánh giá hiệu quả đầu tư trước khi phê duyệt dự án IT.

Business Case giúp so sánh lựa chọn đầu tư và làm rõ điều kiện để lợi ích xuất hiện. Hồ sơ cần bao quát chi phí vòng đời, trách nhiệm nghiệp vụ và những giả định có thể làm thay đổi quyết định phê duyệt.

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: quản lý tài chính và đội dự án đánh giá chi phí, lợi ích và phương án đầu tư IT.

Đề xuất thay hệ thống thường bắt đầu bằng một danh sách tính năng và báo giá. Khi cuộc họp phê duyệt chuyển sang câu hỏi “vì sao cần đầu tư lúc này?”, nhóm dự án lại thiếu bằng chứng về vấn đề kinh doanh. Phần mềm mới có vẻ tốt hơn, nhưng chưa rõ cái tốt hơn ấy có đáng với khoản tiền và năng lực triển khai phải bỏ ra hay không.

Business Case — hồ sơ lập luận cho quyết định đầu tư — cần giải quyết khoảng trống đó. Giá trị của hồ sơ nằm ở khả năng so sánh những lựa chọn thực tế, làm rõ giả định và xác định điều kiện để khoản đầu tư còn hợp lý. Một bản trình bày đẹp nhưng chỉ bảo vệ phương án đã chọn sẽ khiến lãnh đạo khó nhận ra lúc nào nên điều chỉnh hoặc dừng.

Bắt đầu từ tổn thất của cách làm hiện tại

Trước khi mô tả giải pháp, Project Manager cần cùng chủ quy trình xác định vấn đề có thể quan sát. Đơn hàng đang chờ ở bước nào, dữ liệu nào phải đối soát, sự cố nào làm gián đoạn dịch vụ, hay giới hạn nào cản trở tăng trưởng? Những chi tiết này giúp phân biệt nhu cầu kinh doanh với mong muốn sở hữu công nghệ mới. Một chức năng được đề nghị nhiều lần vẫn có thể chỉ xử lý biểu hiện bên ngoài của quy trình chưa thống nhất.

Đường cơ sở phải đi kèm phạm vi và nguồn dữ liệu. Thời gian xử lý trung bình sẽ thiếu ý nghĩa nếu trộn giao dịch đơn giản với giao dịch cần nhiều cấp phê duyệt. Nhóm dự án nên ghi rõ kỳ đo, nhóm khách hàng, ngoại lệ và người xác nhận. Nếu dữ liệu còn yếu, hồ sơ cần thể hiện giới hạn đó và đề xuất cách thu thập thêm, thay vì tạo một con số chính xác giả tạo để hoàn thiện bảng tính.

Sau hiện trạng là diễn biến nếu chưa đầu tư. Có vấn đề sẽ tăng theo số lượng giao dịch; có vấn đề có thể được kiểm soát tạm bằng thay đổi quy trình. Không hành động cũng có chi phí và rủi ro, nhưng không nên mặc định mọi tổn thất hiện tại sẽ được dự án loại bỏ. Một phần có thể bắt nguồn từ chính sách thương mại, năng lực nhân sự hoặc quyết định quản lý nằm ngoài phạm vi hệ thống.

Mục tiêu đầu tư nên mô tả thay đổi nghiệp vụ cần đạt và cách xác nhận. Năng lực lãnh đạo dự án IT thể hiện ở việc nối nhu cầu ấy với phạm vi có thể thực hiện. Khi đã hiểu tổn thất nào cần xử lý, doanh nghiệp mới có cơ sở hỏi liệu một dự án công nghệ lớn có phải lựa chọn phù hợp nhất.

So sánh phương án trước khi bảo vệ một giải pháp

Ít nhất cần một phương án duy trì hiện trạng làm mốc so sánh, một phương án can thiệp tối thiểu nếu khả thi và những lựa chọn đầu tư thực chất. Chẳng hạn, cải tiến luồng phê duyệt trên nền tảng hiện có có thể giải quyết phần lớn thời gian chờ, trong khi thay toàn bộ hệ thống còn tạo năng lực tích hợp dài hạn. Hai lựa chọn trả lời các mức nhu cầu khác nhau; không nên so sánh bằng số tính năng đơn thuần.

The Green Book của HM Treasury là hướng dẫn thẩm định đầu tư công tại Anh, xem xét chi phí, lợi ích và rủi ro giữa các lựa chọn. Doanh nghiệp có thể tham khảo nguyên tắc so sánh này, đồng thời sử dụng dữ liệu và tiêu chí phù hợp với mình. Những tham số dành cho đầu tư công không tự động trở thành tham số tài chính của một doanh nghiệp tại Việt Nam.

Bảng dưới đây là công cụ gợi ý để sàng lọc phương án trước khi tính toán sâu. Tiêu chí bắt buộc cần được kiểm tra riêng, vì một phương án không đáp ứng điều kiện an toàn hoặc khả năng vận hành không thể được cứu bằng điểm tính năng cao.

Lựa chọn	Bằng chứng cần có	Điểm phải làm rõ
Duy trì hiện trạng	Chi phí và rủi ro tiếp tục phát sinh	Giới hạn có thể chịu đến khi nào?
Cải tiến quy trình hiện có	Nguyên nhân chờ và khả năng thay đổi	Lợi ích nào chưa xử lý được?
Mở rộng nền tảng hiện tại	Khả năng tích hợp và giới hạn kiến trúc	Chi phí nâng cấp về sau là gì?
Thay nền tảng theo giai đoạn	Phạm vi chuyển đổi và thử nghiệm	Điều kiện mở rộng đã được định nghĩa chưa?

Một phương án rẻ hơn có thể giữ lại nhiều thao tác thủ công, còn phương án toàn diện có thể vượt khả năng chuyển đổi của tổ chức. Project Manager cần làm rõ sự đánh đổi ấy với người phê duyệt. Sau khi sàng lọc các lựa chọn thực tế, bước tiếp theo là tính đầy đủ số tiền và công sức cần bỏ ra để chúng hoạt động.

Tính chi phí vòng đời và kiểm tra khả năng chi trả

Báo giá mua phần mềm chỉ là một phần của khoản đầu tư. Chi phí còn nằm ở làm sạch dữ liệu, tích hợp, kiểm thử, đào tạo, vận hành song song, hỗ trợ sau chuyển đổi và kết thúc hợp đồng cũ. Nguồn lực nội bộ cũng có chi phí cơ hội: chuyên gia tham gia dự án sẽ không đồng thời hoàn thành những công việc khác. Nếu phần này bị bỏ qua, hồ sơ sẽ đánh giá thấp năng lực thực thi cần thiết.

Cần phân biệt tổng chi phí với lịch dòng tiền. Một phương án có hiệu quả kinh tế dự kiến tốt vẫn có thể tạo áp lực ngân sách ở giai đoạn chuyển đổi. Tài chính phải xác nhận cách xử lý thuế, tỷ giá, lạm phát và thời điểm thanh toán theo bối cảnh doanh nghiệp. Với khoản đầu tư nhiều năm, phương pháp chiết khấu cần nhất quán và có người chịu trách nhiệm về tham số sử dụng.

Các cam kết dài hạn cần được nhìn từ khả năng thay đổi quy mô. Giấy phép, lượng sử dụng, phí lưu trữ, phí tích hợp hoặc dịch vụ hỗ trợ có thể tăng khác nhau khi doanh nghiệp phát triển. Một mức giá ưu đãi ban đầu không giải thích được tổng chi phí tương lai. Nhóm dự án nên yêu cầu những tình huống sử dụng cụ thể và kiểm tra phần chi phí nào có thể kiểm soát, phần nào phụ thuộc điều kiện hợp đồng.

Đây là điểm cần phối hợp năng lực quản lý bộ phận IT với tài chính và mua sắm. Kế hoạch nguồn lực, chi phí vận hành và mức dịch vụ phải cùng mô tả một phương án. Khi chi phí đã được nhìn đầy đủ, phần lợi ích cũng phải chịu một mức kiểm tra tương xứng.

Lợi ích phải có cơ chế hiện thực hóa và chủ sở hữu

Tự động hóa làm giảm thời gian thao tác chưa đồng nghĩa doanh nghiệp giảm chi phí tiền mặt. Khoảng thời gian được giải phóng có thể dùng để xử lý thêm giao dịch, nâng chất lượng hoặc giảm làm thêm giờ. Business Case cần chỉ rõ kịch bản nào sẽ xảy ra và ai có quyền thực hiện thay đổi đó. Nếu chưa có kế hoạch sử dụng năng lực được giải phóng, nên trình bày đó là lợi ích tiềm năng.

Trong ví dụ giả định, một doanh nghiệp muốn tự động đối soát để giảm việc làm lại. Hồ sơ cần tách phần thời gian tiết kiệm với phần chi phí làm thêm giờ có thể tránh. Nếu hai con số phản ánh cùng một thay đổi, cộng chúng sẽ tính lợi ích hai lần. Tương tự, tăng doanh thu dự kiến cần xét năng lực bán hàng, nhu cầu thị trường và chi phí phục vụ phát sinh, không quy toàn bộ kết quả cho hệ thống.

Mỗi lợi ích nên có một chủ sở hữu nghiệp vụ, nguồn đo, đường cơ sở và thời điểm kiểm tra. PMI, trong Benefits Realization Management Framework, nhấn mạnh việc xác định, tạo ra và duy trì lợi ích. Với Business Case, điều này gợi ra yêu cầu thực hành: từ lúc xin phê duyệt phải biết ai sẽ tiếp nhận trách nhiệm sau khi nhóm dự án kết thúc.

Không phải lợi ích nào cũng cần quy thành tiền. Khả năng truy xuất, mức kiểm soát truy cập hoặc tính liên tục của dịch vụ có thể được đánh giá bằng tiêu chí rủi ro và vận hành. Quan trọng là lãnh đạo biết chúng tác động tới quyết định như thế nào. Một khi chi phí và lợi ích đã được gắn với giả định, hồ sơ mới có thể kiểm tra độ bền của kết luận đầu tư.

Thử sức chịu đựng của Business Case trước biến động

Kịch bản cơ sở chỉ mô tả một tương lai có thể xảy ra. Project Manager cần xem điều gì xảy ra nếu thời gian triển khai kéo dài, người dùng áp dụng chậm, lượng giao dịch thấp hơn dự kiến hoặc phí vận hành tăng. Nên ưu tiên các biến có tác động lớn và bằng chứng yếu. Không cần tạo nhiều kịch bản chỉ để làm hồ sơ có vẻ phức tạp.

Phân tích độ nhạy thay đổi từng giả định để tìm điểm làm phương án mất hấp dẫn; phân tích kịch bản kết hợp những thay đổi có thể xảy ra cùng nhau. Kết quả hữu ích là một ngưỡng hành động: nếu chi phí chuyển đổi vượt giới hạn hoặc tỷ lệ áp dụng không đạt mức cần thiết, dự án phải giảm phạm vi, thử nghiệm thêm hay trình lại quyết định. Ngưỡng này cần được thống nhất với người phê duyệt.

Với phần chưa chắc chắn, có thể đề xuất đầu tư theo giai đoạn. Thử nghiệm nhỏ phải trả lời một giả định quan trọng, chẳng hạn khả năng tích hợp hoặc mức chấp nhận của người dùng, và có điều kiện kết thúc. Một pilot kéo dài mà không có tiêu chí quyết định chỉ làm trì hoãn việc nhìn nhận rủi ro. Năng lực quản lý dự án IT giúp chuyển những giả định này thành công việc, đầu ra và mốc đánh giá cụ thể.

Lãnh đạo cũng cần biết phần nào có thể đảo ngược và phần nào tạo cam kết lâu dài. Chi cho khảo sát khác với ký hợp đồng nhiều năm; thử một quy trình khác với chuyển toàn bộ dữ liệu. Cấp vốn nên phù hợp mức bằng chứng đã có. Điều đó dẫn đến cách trình bày hồ sơ để người phê duyệt nhìn được quyết định trước mắt, thay vì bị cuốn vào toàn bộ chi tiết kỹ thuật.

Phê duyệt một quyết định có điều kiện và tiếp tục cập nhật

Trang tóm tắt nên nêu vấn đề, lựa chọn được đề xuất, phương án thay thế đáng chú ý, tổng nguồn lực, lợi ích kỳ vọng và những giả định có thể thay đổi kết luận. Phần đề nghị phải rõ: xin duyệt nghiên cứu tiếp, triển khai một giai đoạn hay cam kết toàn bộ khoản đầu tư. Người đọc không nên phải suy đoán phạm vi phê duyệt từ tổng ngân sách trong phụ lục.

Trước cuộc họp, chủ quy trình xác nhận hiện trạng và lợi ích; tài chính xác nhận cách tính; IT xác nhận tính khả thi; mua sắm làm rõ điều kiện thương mại. Những điểm còn bất đồng nên được trình bày cùng lựa chọn xử lý. Năng lực lãnh đạo công nghệ cần thiết khi khoản đầu tư phải cân bằng mục tiêu của nhiều bộ phận.

Sau phê duyệt, Business Case cần có phiên bản và lịch rà soát tại những mốc quyết định quan trọng. Chi phí thực tế, phạm vi thay đổi, bằng chứng thử nghiệm và kỳ vọng lợi ích phải được cập nhật. Khoản tiền đã chi không chứng minh rằng phần đầu tư tiếp theo còn đáng thực hiện. Hồ sơ tốt cho phép doanh nghiệp nhận ra sự thay đổi này đủ sớm để chọn lại phương án.

Bước đầu có thể làm ngay là chọn một đề xuất đang chuẩn bị phê duyệt, bổ sung phương án can thiệp tối thiểu và yêu cầu chủ sở hữu xác nhận cơ chế tạo lợi ích. Khi ba yếu tố — lựa chọn, giả định, trách nhiệm — được làm rõ, Business Case mới trở thành công cụ quản trị khoản đầu tư xuyên suốt dự án.