Cách đánh giá giá trị giải pháp công nghệ

Cách đánh giá phù hợp là thiết lập trạng thái trước triển khai, xác định kết quả cần cải thiện, quy đổi những thay đổi có thể đo được thành KPI và theo dõi chúng trong một khoảng thời gian đủ dài. Giá trị khi đó được xem xét đồng thời qua lợi ích, tổng chi phí sở hữu, tác động vận hành, khả năng tạo kết quả kinh doanh và các điều kiện khiến lợi ích dự kiến không đạt được.

Bắt đầu từ kết quả doanh nghiệp cần cải thiện

Đánh giá giá trị nên bắt đầu bằng câu hỏi giải pháp phải thay đổi kết quả nào, thay vì giải pháp có những tính năng nào. Một chức năng chỉ có giá trị kinh tế khi nó tác động đến công việc hoặc kết quả có ý nghĩa đối với doanh nghiệp.

Ví dụ, hệ thống tự động hóa xử lý đơn hàng không nên được đánh giá chủ yếu bằng số workflow có thể cấu hình. Những chỉ số sát với giá trị hơn là thời gian xử lý mỗi đơn, tỷ lệ sai sót, số giờ lao động cần cho một đơn, khả năng xử lý trong giờ cao điểm và chi phí trên mỗi giao dịch.

Có thể thiết lập một chuỗi đo lường đơn giản:

Tính năng → thay đổi quy trình → thay đổi KPI → tác động kinh doanh

Nếu giải pháp tự động nhập dữ liệu, thay đổi quy trình có thể là giảm thao tác thủ công. KPI tương ứng có thể là số phút xử lý mỗi hồ sơ hoặc số hồ sơ mỗi nhân viên. Tác động kinh doanh cuối cùng mới là phần thời gian lao động tiết kiệm, khả năng xử lý thêm khối lượng công việc hoặc giảm chi phí lỗi.

Cách tiếp cận này cũng phù hợp với cách các mô hình đánh giá công nghệ tách chất lượng kỹ thuật khỏi kết quả sử dụng. ISO/IEC 25010:2023 xác định mô hình chất lượng cho sản phẩm ICT để các đặc tính của sản phẩm có thể được chỉ định, đo lường và đánh giá, thay vì coi sự tồn tại của chức năng là bằng chứng đủ về chất lượng hoặc giá trị.

Doanh nghiệp vì vậy cần một baseline trước khi triển khai. Nếu thời gian xử lý hiện tại là 20 phút một giao dịch nhưng không được ghi nhận trước khi thay hệ thống, rất khó chứng minh việc giảm xuống 12 phút là giá trị do giải pháp tạo ra hay chỉ là biến động bình thường của hoạt động.

Đo lợi ích bằng KPI có thể kiểm chứng

Lợi ích của công nghệ thường xuất hiện ở nhiều dạng hơn tiết kiệm trực tiếp. Với các giải pháp phục vụ vận hành doanh nghiệp, giá trị có thể đến từ giảm chi phí, tăng năng suất nhân sự, tăng độ ổn định, rút ngắn thời gian đưa sản phẩm hoặc thay đổi ra thị trường và giảm các nguồn lãng phí.

AWS Cloud Value Framework cũng sử dụng nhiều chiều giá trị thay vì chỉ xét chi phí, gồm tiết kiệm chi phí, năng suất nhân sự, khả năng phục hồi vận hành, sự linh hoạt kinh doanh và tính bền vững. AWS cho biết framework này được xây dựng để đo và theo dõi giá trị qua các KPI vận hành và tài chính.

Tùy mục tiêu của giải pháp, doanh nghiệp có thể chọn một số KPI trực tiếp:

·         Thời gian xử lý một giao dịch

·         Chi phí trên mỗi giao dịch, khách hàng hoặc đơn vị sản phẩm

·         Số giờ lao động cho một quy trình

·         Sản lượng xử lý trên mỗi nhân viên

·         Tỷ lệ lỗi hoặc công việc phải làm lại

·         Thời gian ngừng hệ thống

·         Thời gian khôi phục sau sự cố

·         Thời gian triển khai một thay đổi

·         Thời gian từ yêu cầu đến khi chức năng được đưa vào sử dụng

·         Doanh thu hoặc biên lợi nhuận liên quan đến quy trình được cải thiện

Đối với chi phí công nghệ biến đổi theo quy mô, chi phí đơn vị thường có ý nghĩa hơn tổng hóa đơn. FinOps Foundation mô tả unit cost như một cách liên kết chi tiêu công nghệ với đơn vị tạo giá trị của doanh nghiệp, chẳng hạn người dùng, thuê bao hoặc giao dịch. Khi chi phí công nghệ tăng cùng với quy mô hoạt động, tổng chi phí tăng chưa chắc phản ánh hiệu quả giảm; điều quan trọng là chi phí cho mỗi đơn vị giá trị thay đổi như thế nào.

Ví dụ, chi phí vận hành một nền tảng tăng từ 500 triệu lên 600 triệu đồng mỗi năm có vẻ bất lợi nếu chỉ nhìn vào ngân sách. Nhưng nếu số giao dịch tăng từ 1 triệu lên 1,5 triệu, chi phí trên mỗi giao dịch đã giảm từ 500 xuống 400 đồng. Trong trường hợp đó, hệ thống đang xử lý quy mô lớn hơn với chi phí đơn vị thấp hơn 20%.

Tính tổng chi phí sở hữu thay vì chỉ nhìn giá mua

Lợi ích chỉ tạo thành giá trị khi được đặt cạnh toàn bộ chi phí cần thiết để đạt được lợi ích đó. Giá giấy phép hoặc phí thuê bao thường chỉ là một phần của tổng chi phí sở hữu, hay Total Cost of Ownership.

TCO nên bao gồm các khoản có quan hệ trực tiếp với vòng đời giải pháp, chẳng hạn:

·         Phí bản quyền, thuê bao hoặc hạ tầng

·         Chi phí triển khai và tích hợp

·         Chi phí chuyển đổi hoặc làm sạch dữ liệu

·         Thời gian nhân sự nội bộ tham gia dự án

·         Đào tạo và quản lý thay đổi

·         Vận hành, hỗ trợ và bảo trì

·         Chi phí nâng cấp hoặc mở rộng

·         Chi phí bảo mật, kiểm soát và tuân thủ cần bổ sung

·         Chi phí chuyển đổi khỏi giải pháp khi kết thúc sử dụng

Một mô hình cơ bản có thể tính:

Giá trị ròng = Tổng lợi ích quy đổi được − Tổng chi phí sở hữu

Nếu doanh nghiệp đầu tư tổng cộng 2 tỷ đồng trong ba năm và xác định được 3 tỷ đồng lợi ích có thể quy đổi, giá trị ròng là 1 tỷ đồng.

ROI có thể được biểu diễn:

ROI = (Tổng lợi ích − Tổng chi phí) / Tổng chi phí × 100%

Với ví dụ trên, ROI là 50%.

Tuy nhiên, ROI không nên trở thành thước đo duy nhất. Hai dự án cùng ROI 50% có thể khác đáng kể về thời điểm thu được lợi ích, rủi ro triển khai hoặc mức vốn ban đầu. Vì vậy, doanh nghiệp còn cần xem thời gian hoàn vốn và dòng lợi ích theo từng giai đoạn.

Đối với các dự án chuyển đổi lớn, chi phí thay đổi cũng cần được tính riêng. AWS lưu ý rằng việc đánh giá giá trị sau chuyển đổi phải đặt cạnh nguồn lực, thời gian và công sức cần cho quá trình di chuyển, thay vì chỉ so sánh trạng thái vận hành sau khi hệ thống mới đã ổn định.

Đánh giá tác động thực tế đến vận hành

Một giải pháp có business case tốt trên bảng tính vẫn có thể tạo giá trị thấp nếu làm hoạt động hàng ngày phức tạp hơn. Vì vậy, doanh nghiệp cần đo hệ thống trong môi trường sử dụng thực tế.

Ba nhóm tác động đặc biệt quan trọng là năng suất, độ ổn định và khả năng thay đổi.

Với năng suất, số giờ được “tiết kiệm” chỉ có giá trị nếu thời gian đó thực sự được giải phóng hoặc chuyển sang công việc tạo giá trị hơn. Nếu một công cụ giảm 10 phút nhập liệu nhưng nhân viên phải mất thêm 8 phút kiểm tra và sửa kết quả, lợi ích thực chỉ còn khoảng 2 phút.

Với độ ổn định, cần đo các KPI như số sự cố, thời gian gián đoạn, Mean Time to Recovery hoặc tỷ lệ giao dịch thất bại. Giá trị không nhất thiết xuất hiện dưới dạng doanh thu mới; tránh được thời gian chết và công việc khôi phục cũng là lợi ích vận hành. Khả năng phục hồi vận hành vì vậy được xem là một chiều riêng trong các framework đánh giá giá trị công nghệ như AWS Cloud Value Framework.

Với khả năng thay đổi, doanh nghiệp có thể theo dõi thời gian cần để đưa một yêu cầu mới vào sản xuất, thời gian cấp tài nguyên, số bước thủ công hoặc tỷ lệ triển khai thất bại. Giá trị ở đây là giảm thời gian từ quyết định kinh doanh đến khả năng thực thi.

Điều cần tránh là biến mọi cải thiện kỹ thuật thành lợi ích tài chính một cách tự động. Hệ thống nhanh hơn 30% không đồng nghĩa doanh thu tăng 30%. Muốn quy đổi thành giá trị kinh doanh phải chứng minh bước trung gian: hiệu năng tốt hơn đã giảm thời gian chờ, tăng số giao dịch, giảm nhân lực, cải thiện tỷ lệ hoàn thành hoặc tạo ra một kết quả đo được khác.

Kiểm tra mức độ sử dụng và khả năng duy trì lợi ích

Giải pháp chỉ tạo giá trị khi người dùng và quy trình thực sự sử dụng năng lực mà doanh nghiệp đã đầu tư. Vì vậy, mức độ adoption là điều kiện để các lợi ích dự kiến trở thành lợi ích thực tế.

Các chỉ số có thể theo dõi gồm:

·         Tỷ lệ người dùng mục tiêu hoạt động thường xuyên

·         Tỷ lệ quy trình đã chuyển sang hệ thống mới

·         Tỷ lệ giao dịch vẫn phải xử lý ngoài hệ thống

·         Tần suất sử dụng các chức năng tạo giá trị chính

·         Số bước hoặc công cụ cũ vẫn phải duy trì song song

·         Số yêu cầu hỗ trợ liên quan đến khó khăn sử dụng

Một hệ thống có 1.000 tài khoản được cấp nhưng chỉ 300 người dùng thường xuyên không nên được đánh giá trên giả định 1.000 người đang tạo lợi ích. Tương tự, việc triển khai một chức năng tự động không chứng minh đã tiết kiệm lao động nếu phần lớn nhân viên vẫn thực hiện quy trình thủ công cũ.

Adoption cũng giải thích vì sao pilot và đo sau triển khai quan trọng. Business case ban đầu chủ yếu chứa giả định. Sau khi vận hành, doanh nghiệp có dữ liệu để thay các giả định bằng kết quả quan sát được và xác định lợi ích nào đang thực sự tồn tại.

So sánh giá trị nhận được với trạng thái không đầu tư

Sai lệch phổ biến khi đánh giá công nghệ là chỉ hỏi hệ thống mới tạo ra bao nhiêu lợi ích mà không xác định điều gì sẽ xảy ra nếu doanh nghiệp không đầu tư.

Đối chứng phù hợp có thể là:

·         Tiếp tục dùng hệ thống hiện tại

·         Tự xây dựng giải pháp

·         Thuê dịch vụ thay cho đầu tư hệ thống

·         Nâng cấp một phần thay vì thay toàn bộ

·         Không thay đổi quy trình

Giá trị gia tăng nên được tính từ chênh lệch giữa các phương án, không phải toàn bộ kết quả kinh doanh sau khi triển khai.

Ví dụ, nếu hệ thống mới giúp chi phí vận hành còn 8 tỷ đồng mỗi năm nhưng hệ thống cũ dự kiến chỉ tốn 8,5 tỷ đồng, phần tiết kiệm liên quan trực tiếp là 500 triệu đồng, không phải 8 tỷ đồng. Nếu hệ thống cũ còn cần khoản nâng cấp 1 tỷ đồng trong năm tiếp theo, khoản chi phí tránh được đó có thể được đưa vào so sánh nếu có cơ sở rõ ràng.

Cách so sánh này hạn chế việc gán cho công nghệ những kết quả do tăng trưởng thị trường, thay đổi nhân sự hoặc các dự án khác tạo ra.

Đưa rủi ro và điều kiện thực hiện vào giá trị cuối cùng

Giá trị dự kiến không tương đương giá trị chắc chắn nhận được. Một giải pháp có thể có ROI lý thuyết cao nhưng phụ thuộc vào tích hợp phức tạp, dữ liệu chưa đạt chất lượng, khả năng sử dụng thấp hoặc nhà cung cấp mà doanh nghiệp khó thay thế.

Do đó, trước khi ra kết luận cần xác định điều kiện để lợi ích xuất hiện:

·         Dữ liệu đầu vào có đủ chất lượng hay không

·         Hệ thống có tích hợp được với quy trình hiện tại hay không

·         Người dùng có chuyển sang cách làm mới hay không

·         Hạ tầng có đáp ứng yêu cầu hiệu năng và độ sẵn sàng hay không

·         Doanh nghiệp có đủ năng lực vận hành giải pháp hay không

·         Chi phí có tăng mạnh khi số người dùng hoặc giao dịch tăng hay không

·         Doanh nghiệp có phụ thuộc quá mức vào một nhà cung cấp hoặc công nghệ hay không

Các tiêu chí kỹ thuật không nên bị tách khỏi business value. ISO/IEC 25010:2023 cung cấp một mô hình gồm chín đặc tính chất lượng cho sản phẩm ICT và cho phép sử dụng chúng khi xác định yêu cầu, tiêu chí chấp nhận và các phép đo chất lượng. Điều này cho thấy giá trị kinh doanh cần được bảo vệ bởi mức chất lượng kỹ thuật đủ để giải pháp hoạt động trong điều kiện sử dụng thực tế.

Doanh nghiệp cũng có thể xây dựng ba kịch bản thay vì một dự báo duy nhất: thận trọng, cơ sở và tích cực. Nếu dự án chỉ tạo giá trị trong kịch bản tích cực nhưng âm trong kịch bản cơ sở, kết luận sẽ khác với một dự án vẫn có giá trị dương ngay cả khi adoption hoặc mức tiết kiệm thấp hơn dự kiến.

Theo dõi giá trị sau triển khai bằng cùng một bộ chỉ số

Đánh giá giá trị không kết thúc khi hợp đồng được ký hoặc hệ thống go-live. Giá trị thực chỉ có thể xác nhận khi KPI sau triển khai được so với baseline và mục tiêu ban đầu.

Một scorecard có thể giữ số lượng chỉ số tương đối nhỏ nhưng bao phủ đủ bốn lớp:

·         Lợi ích: Chi phí tiết kiệm, doanh thu hỗ trợ, năng suất hoặc công việc tránh được

·         Chi phí: TCO, chi phí đơn vị và chi phí phát sinh ngoài kế hoạch

·         Vận hành: Thời gian xử lý, lỗi, độ sẵn sàng, thời gian khôi phục hoặc tốc độ triển khai

·         Sử dụng: Adoption, tỷ lệ quy trình chuyển đổi và mức sử dụng chức năng chính

Các chỉ số phải được đo trên cùng định nghĩa trước và sau triển khai. Nếu baseline tính thời gian xử lý từ lúc nhân viên bắt đầu thao tác nhưng số liệu sau triển khai tính từ lúc hồ sơ được tạo, chênh lệch không còn phản ánh cùng một hiện tượng.

Tần suất đánh giá cũng cần phù hợp với loại lợi ích. Tiết kiệm hạ tầng có thể xuất hiện sớm, trong khi lợi ích từ thay đổi quy trình hoặc năng suất nhân sự có thể cần thời gian để người dùng thích nghi. Vì vậy, một lần đo ngay sau go-live chưa đủ để kết luận toàn bộ giá trị của giải pháp.

Giá trị giải pháp công nghệ được xác định tốt nhất bằng chênh lệch giữa trạng thái doanh nghiệp trước và sau khi áp dụng giải pháp, sau khi tính đầy đủ chi phí và điều kiện để lợi ích xảy ra. Doanh nghiệp nên bắt đầu từ một kết quả kinh doanh cụ thể, thiết lập baseline, chọn KPI có thể đo, tính TCO và giá trị ròng, sau đó kiểm tra tác động vận hành và mức độ sử dụng thực tế.

ROI có thể giúp quy đổi giá trị thành ngôn ngữ tài chính, nhưng không thay thế được các chỉ số về năng suất, khả năng phục hồi, tốc độ thay đổi hay adoption. Một giải pháp tạo giá trị khi những cải thiện đó có thể quan sát, đo lường và duy trì trong hoạt động thực tế — không chỉ khi sản phẩm có nhiều tính năng hoặc có một business case hấp dẫn trước triển khai.