Cách xây dựng bảng chấm điểm giải pháp công nghệ

Về cơ bản, điểm của một giải pháp có thể được chuẩn hóa theo công thức:

Điểm tổng = Σ (Trọng số tiêu chí × Điểm tiêu chí / Điểm tối đa)

Nếu tổng trọng số bằng 100 và thang điểm là 1–5, kết quả cuối cùng có thể quy đổi trực tiếp về thang 100. Tuy nhiên, điểm tổng chỉ nên được sử dụng sau khi giải pháp vượt qua các điều kiện loại như yêu cầu pháp lý, an toàn thông tin, khả năng tích hợp bắt buộc hoặc giới hạn ngân sách không thể thay đổi.

Xác định điều kiện bắt buộc trước khi xây dựng tiêu chí chấm điểm

Sai lầm phổ biến là đưa mọi yêu cầu vào cùng một phép tính. Cách này cho phép một điểm mạnh bù trừ một điểm yếu mà trên thực tế doanh nghiệp không thể chấp nhận.

Ví dụ, một hệ thống có thể đạt điểm rất cao về chức năng và giá thành nhưng không đáp ứng yêu cầu bắt buộc về lưu trữ dữ liệu, xác thực, quyền truy cập hoặc tích hợp với hệ thống lõi. Nếu những yêu cầu này chỉ nhận trọng số như các tiêu chí thông thường, giải pháp vẫn có khả năng đứng đầu bảng điểm.

Do đó, trước khi tính điểm nên chia yêu cầu thành hai lớp:

·         Điều kiện bắt buộc: Giải pháp phải đạt mức tối thiểu mới được tiếp tục đánh giá

·         Tiêu chí có thể đánh đổi: Mức độ mạnh yếu có thể được phản ánh bằng điểm và trọng số

Một điều kiện bắt buộc nên có kết quả rõ như Đạt/Không đạt, hoặc có ngưỡng tối thiểu. Chẳng hạn, doanh nghiệp có thể quy định mọi tiêu chí bảo mật trọng yếu phải đạt ít nhất 3/5; bất kỳ giải pháp nào thấp hơn ngưỡng này đều không được lựa chọn dù điểm tổng cao.

Cách tiếp cận này phù hợp với bản chất của quản trị rủi ro công nghệ: đánh giá nhà cung cấp và sản phẩm không chỉ dựa trên chức năng mà còn phải xem xét rủi ro trong quá trình mua, tích hợp, triển khai và vận hành. NIST cũng xem việc xác định yêu cầu đối với nhà cung cấp và thực hiện due diligence là thành phần của quản trị rủi ro chuỗi cung ứng công nghệ.

Chuyển yêu cầu kinh doanh và kỹ thuật thành tiêu chí có thể chấm

Mỗi tiêu chí phải trả lời được câu hỏi: Người chấm sẽ dựa vào bằng chứng nào để phân biệt điểm 2, 3, 4 và 5?

Nếu không trả lời được, tiêu chí còn quá mơ hồ.

Thay vì dùng các tiêu chí như “công nghệ tốt”, “dễ sử dụng” hoặc “bảo mật cao”, doanh nghiệp nên chuyển chúng thành thuộc tính có thể kiểm tra.

Một bảng đánh giá giải pháp doanh nghiệp có thể tổ chức thành các nhóm sau:

Đây không phải danh sách cố định. Tiêu chí phải xuất phát từ yêu cầu thực tế của quyết định.

Với sản phẩm phần mềm hoặc ICT, ISO/IEC 25010:2023 có thể được dùng như một nguồn tham chiếu để kiểm tra xem bộ tiêu chí chất lượng đã đủ rộng hay chưa. Tiêu chuẩn này định nghĩa mô hình chất lượng sản phẩm ICT và phần mềm gồm chín nhóm đặc tính, phục vụ việc xác định yêu cầu, mục tiêu kiểm thử, tiêu chí kiểm soát chất lượng và tiêu chí nghiệm thu.

Điều đó không có nghĩa doanh nghiệp phải đưa toàn bộ đặc tính của một tiêu chuẩn vào bảng chấm điểm. Chỉ những tiêu chí ảnh hưởng đến quyết định hiện tại mới nên được giữ lại.

Gán trọng số theo mức độ ảnh hưởng đến quyết định

Trọng số thể hiện một tiêu chí quan trọng đến mức nào so với các tiêu chí còn lại. Vì vậy, tổng trọng số nên bằng 100% để người đánh giá nhìn thấy rõ sự phân bổ ưu tiên.

Một cấu hình minh họa có thể là:

Các tỷ lệ trên chỉ là ví dụ thiết kế, không phải benchmark áp dụng cho mọi doanh nghiệp.

Nếu một dự án chủ yếu nhằm giải quyết vấn đề nghiệp vụ, phần phù hợp nghiệp vụ có thể nhận trọng số lớn. Với hệ thống nằm trong hạ tầng trọng yếu, bảo mật, khả năng phục hồi hoặc khả năng tích hợp có thể quan trọng hơn. Với một công cụ có vòng đời ngắn và dễ thay thế, các yếu tố đó lại có thể nhận trọng số thấp hơn.

Trọng số nên được thống nhất trước khi biết nhà cung cấp nào đang dẫn đầu. Nếu trọng số được thay đổi sau khi nhìn thấy kết quả, bảng điểm rất dễ trở thành công cụ hợp thức hóa một lựa chọn đã có sẵn.

Ngoài ra cần tránh hai lỗi:

·         Chia một ưu tiên thành nhiều tiêu chí gần giống nhau khiến nó vô tình nhận trọng số thực tế lớn hơn dự kiến

·         Cho quá nhiều tiêu chí trọng số rất nhỏ khiến các khác biệt quan trọng bị pha loãng

Một tiêu chí chỉ nên tồn tại nếu kết quả của nó có khả năng làm thay đổi quyết định.

Thiết kế thang điểm bằng mô tả hành vi thay vì cảm nhận

Cùng một tiêu chí nhưng nếu mỗi người hiểu điểm 4 theo một cách khác nhau, kết quả cuối cùng vẫn mang tính chủ quan.

Với thang 1–5, doanh nghiệp có thể thiết kế logic chung như sau:

Sau đó phải cụ thể hóa thang điểm cho các tiêu chí quan trọng.

Ví dụ, “khả năng tích hợp” không nên được chấm 5 chỉ vì nhà cung cấp nói rằng sản phẩm “có API”. Người đánh giá cần xem API đó có hỗ trợ đúng nghiệp vụ cần tích hợp hay không, cơ chế xác thực ra sao, giới hạn sử dụng thế nào, dữ liệu nào có thể trao đổi và kết quả đã được kiểm chứng qua tài liệu hoặc thử nghiệm chưa.

Tương tự, chi phí không nên chỉ dựa trên giá license. Tiêu chí phải xác định rõ phạm vi chi phí được so sánh: triển khai, tích hợp, migration, hạ tầng, vận hành, hỗ trợ, nâng cấp và chi phí chuyển đổi nếu chúng có ảnh hưởng đáng kể đến quyết định.

Mỗi điểm quan trọng nên gắn với một dạng bằng chứng như:

·         Tài liệu kỹ thuật

·         Kết quả demo theo kịch bản đã định trước

·         Proof of concept

·         Báo cáo kiểm thử

·         Hồ sơ bảo mật hoặc tuân thủ

·         SLA và điều khoản hợp đồng

·         Dữ liệu chi phí

·         Tham chiếu từ triển khai thực tế

Nguyên tắc là chấm bằng bằng chứng, không chấm bằng mức độ thuyết phục của buổi trình bày.

Tính điểm có trọng số nhưng không để điểm tổng che khuất rủi ro

Giả sử doanh nghiệp sử dụng trọng số ở trên và thang điểm 1–5.

Giải pháp A nhận các điểm:

Điểm quy đổi của từng tiêu chí được tính bằng:

Trọng số × Điểm / 5

Điểm 79/100 giúp so sánh giải pháp A với các phương án khác, nhưng chưa tự động có nghĩa A là lựa chọn phù hợp.

Doanh nghiệp nên đọc kết quả ở ba tầng:

1.    Điều kiện bắt buộc: Giải pháp có vượt tất cả ngưỡng loại hay không

2.    Điểm tổng: Giải pháp tạo giá trị tổng hợp như thế nào theo các ưu tiên đã thống nhất

3.    Hồ sơ điểm: Điểm yếu tập trung ở đâu và doanh nghiệp có chấp nhận trade-off đó hay không

Hai giải pháp có thể cùng đạt khoảng 80 điểm nhưng mang hồ sơ rủi ro hoàn toàn khác nhau. Một giải pháp có thể mạnh về nghiệp vụ nhưng tốn nhiều công tích hợp; giải pháp còn lại tích hợp tốt nhưng thiếu một số chức năng. Điểm tổng không thể thay thế việc xem xét sự khác biệt đó.

Đặc biệt, rủi ro bảo mật và nhà cung cấp nên được kiểm tra như những yếu tố thực chất của việc mua công nghệ, thay vì chỉ là vài điểm cộng hoặc trừ. NIST SP 800-161 Rev. 1 nhấn mạnh việc nhận diện, đánh giá và giảm thiểu rủi ro liên quan đến sản phẩm, dịch vụ và chuỗi cung ứng công nghệ trong hoạt động quản trị rủi ro của tổ chức.

Kiểm thử bảng điểm trước khi dùng để ra quyết định

Một bảng chấm điểm có thể đúng về mặt công thức nhưng vẫn cho kết quả kém nếu trọng số hoặc mô tả điểm quá nhạy.

Trước khi phê duyệt kết quả, doanh nghiệp nên thực hiện ít nhất ba kiểm tra.

Kiểm tra độ nhất quán giữa người chấm

Cho từ hai người trở lên chấm độc lập một số tiêu chí bằng cùng bộ bằng chứng. Nếu một người cho 2 và người khác cho 5, vấn đề thường nằm ở định nghĩa tiêu chí hoặc mô tả thang điểm, không phải ở phép tính.

Khi đó cần làm rõ điều kiện để đạt từng mức trước khi tiếp tục chấm.

Kiểm tra độ nhạy của trọng số

Thử thay đổi những trọng số quan trọng trong một phạm vi hợp lý và tính lại kết quả.

Ví dụ, nếu tăng hoặc giảm 20% trọng số tương đối của hai tiêu chí quan trọng nhất đã khiến vị trí số một và số hai đảo liên tục, quyết định đang rất nhạy với giả định về ưu tiên. Doanh nghiệp nên xem xét trực tiếp trade-off giữa hai phương án thay vì coi chênh lệch vài điểm là kết luận chắc chắn.

Ngược lại, nếu một giải pháp vẫn đứng đầu qua nhiều cấu hình trọng số hợp lý, kết quả có độ ổn định cao hơn.

Kiểm tra chất lượng bằng chứng

Mỗi điểm cao cần truy ngược được về căn cứ đã sử dụng.

Một capability chỉ xuất hiện trên slide bán hàng không nên có mức độ tin cậy ngang với capability đã được kiểm chứng qua tài liệu kỹ thuật, demo theo kịch bản hoặc proof of concept. Nếu độ tin cậy của bằng chứng khác nhau đáng kể, doanh nghiệp có thể ghi riêng trạng thái Đã xác minh/Chưa xác minh thay vì cố nhét thêm một trọng số vào công thức.

Bước kiểm thử cuối cùng giúp bảng chấm điểm thực hiện đúng chức năng: tạo ra một logic đánh giá nhất quán và có thể giải thích, chứ không tạo ra vẻ chính xác bằng một con số duy nhất.

Một bảng chấm điểm giải pháp công nghệ có giá trị khi ba thành phần hoạt động cùng nhau: tiêu chí xác định điều gì cần đánh giá, trọng số thể hiện mức độ quan trọng và thang điểm quy định bằng chứng nào tương ứng với từng mức.

Doanh nghiệp nên xây dựng bảng theo thứ tự: xác định điều kiện bắt buộc, chuyển yêu cầu thành tiêu chí đo được, gán trọng số, mô tả thang điểm, thu thập bằng chứng, tính điểm có trọng số rồi kiểm tra độ nhạy của kết quả. Điểm tổng khi đó là công cụ hỗ trợ so sánh; quyết định cuối cùng vẫn phải xét các ngưỡng bắt buộc, hồ sơ rủi ro và trade-off giữa những phương án đứng đầu.