Cách đánh giá mức độ phù hợp công nghệ

Cách tiếp cận này phù hợp với nguyên tắc của ISO/IEC 25030:2019: yêu cầu chất lượng cần được xác định từ nhu cầu của các bên liên quan và được chuyển thành tiêu chí có thể đánh giá khách quan. ISO/IEC 25010:2023 cũng sử dụng các đặc tính chất lượng làm cơ sở để xác định, đo lường và đánh giá sản phẩm ICT thay vì dựa vào nhận định chung chung.

Vì vậy, doanh nghiệp nên đánh giá theo chuỗi:

Nhu cầu thực tế → tiêu chí đo lường → kiểm tra mức đáp ứng → thử nghiệm trong bối cảnh sử dụng → xác định khoảng cách → quyết định triển khai

Trọng tâm không phải là hỏi “công nghệ này tốt không?”, mà là “công nghệ này có đáp ứng đủ những điều kiện mà doanh nghiệp thực sự cần hay không?”.

Xác định nhu cầu trước khi đánh giá công nghệ

Sai lệch thường xuất hiện ngay từ đầu nếu doanh nghiệp lấy danh sách tính năng của sản phẩm làm tiêu chuẩn đánh giá. Khi đó, những gì công nghệ cung cấp sẽ vô tình trở thành những gì doanh nghiệp cho rằng mình cần.

Thứ tự nên được đảo lại: xác định yêu cầu trước, sau đó mới đối chiếu công nghệ.

Mỗi nhu cầu nên được chuyển thành một yêu cầu có thể kiểm chứng. Chẳng hạn, thay vì ghi “hệ thống phải xử lý đơn hàng nhanh”, doanh nghiệp cần xác định rõ:

·         Quy trình hoặc tác vụ nào cần cải thiện

·         Người dùng hoặc bộ phận nào chịu tác động

·         Kết quả hiện tại đang được đo bằng chỉ số nào

·         Mức kết quả mong muốn là bao nhiêu

·         Điều kiện nào bắt buộc phải đáp ứng

·         Điều kiện nào chỉ mang tính ưu tiên

Ví dụ, một doanh nghiệp muốn áp dụng công nghệ tự động hóa cho xử lý đơn hàng có thể đo thời gian xử lý trung bình, số bước thủ công, tỷ lệ lỗi nhập liệu và số trường hợp phải xử lý ngoại lệ. Công nghệ chỉ được xem là phù hợp khi cải thiện các chỉ số liên quan mà không tạo ra vấn đề nghiêm trọng ở những phần khác của quy trình.

ISO/IEC 25030:2019 nhấn mạnh việc xác định và quản trị yêu cầu chất lượng, đồng thời xem các tiêu chí khách quan là cơ sở để đánh giá hệ thống hoặc phần mềm có đáp ứng giá trị kỳ vọng hay không.

Phân biệt yêu cầu bắt buộc và yêu cầu ưu tiên

Không phải tiêu chí nào cũng nên được bù trừ bằng điểm số.

Một số yêu cầu có thể chấp nhận mức đáp ứng khác nhau, chẳng hạn mức độ thuận tiện của giao diện hoặc thời gian hoàn thành một tác vụ. Ngược lại, một số điều kiện có thể là tiêu chí loại trực tiếp, ví dụ:

·         Không đáp ứng yêu cầu pháp lý bắt buộc

·         Không thể tích hợp với hệ thống trọng yếu

·         Không đáp ứng yêu cầu kiểm soát truy cập hoặc bảo vệ dữ liệu bắt buộc

·         Không xử lý được một nghiệp vụ cốt lõi

·         Không đáp ứng điều kiện vận hành tối thiểu của doanh nghiệp

Nếu một điều kiện bắt buộc không đạt, tổng điểm cao ở những tiêu chí còn lại không đủ để chứng minh công nghệ phù hợp.

Đánh giá mức độ đáp ứng nhu cầu nghiệp vụ

Lớp đánh giá đầu tiên là business fit: công nghệ có giải quyết đúng vấn đề khiến doanh nghiệp xem xét đầu tư hay không.

Doanh nghiệp nên lập ma trận giữa các yêu cầu nghiệp vụ và khả năng thực tế của công nghệ.

Điểm quan trọng là phân biệt giữa có tính năng và đáp ứng yêu cầu.

Hai hệ thống đều có chức năng phê duyệt, nhưng một hệ thống chỉ hỗ trợ một cấp duyệt trong khi quy trình doanh nghiệp cần nhiều cấp, điều kiện phân nhánh và phân quyền theo giá trị giao dịch. Tên chức năng giống nhau nhưng mức độ phù hợp hoàn toàn khác nhau.

Doanh nghiệp vì thế nên kiểm tra công nghệ bằng các kịch bản nghiệp vụ thực tế thay vì chỉ dựa vào danh sách chức năng hoặc bản trình diễn được nhà cung cấp chuẩn bị sẵn.

Đánh giá mức độ phù hợp với quy trình hiện tại

Một công nghệ có thể đáp ứng chức năng nhưng vẫn không phù hợp nếu buộc doanh nghiệp thay đổi quá nhiều bước vận hành mà không tạo ra lợi ích tương ứng.

Việc đánh giá cần xem xét toàn bộ luồng công việc:

Đầu vào → xử lý → phê duyệt → trao đổi dữ liệu → ngoại lệ → đầu ra

Với từng bước, cần xác định công nghệ:

·         Giữ nguyên

·         Tự động hóa

·         Loại bỏ

·         Thay đổi

·         Tạo thêm bước mới

Sau đó đo tác động lên các KPI của quy trình như thời gian chu kỳ, số thao tác thủ công, tỷ lệ lỗi, số lần chuyển giao công việc hoặc khối lượng xử lý lại.

Một thay đổi quy trình không mặc định là bất lợi. Công nghệ mới có thể yêu cầu doanh nghiệp bỏ một cách làm cũ vốn kém hiệu quả. Vấn đề cần đánh giá là chi phí và rủi ro của thay đổi có tương xứng với giá trị tạo ra hay không.

Ví dụ, nếu hệ thống mới giảm đáng kể các bước nhập liệu lặp lại nhưng yêu cầu chuẩn hóa dữ liệu đầu vào, thay đổi đó có thể hợp lý. Ngược lại, nếu nhân viên phải nhập cùng một thông tin vào thêm một hệ thống chỉ vì hai nền tảng không tích hợp được, công nghệ đang chuyển chi phí kỹ thuật thành chi phí vận hành.

Kiểm tra các trường hợp ngoài quy trình chuẩn

Pilot không nên chỉ kiểm tra trường hợp “happy path”.

Các tình huống cần thử có thể bao gồm:

·         Dữ liệu thiếu hoặc sai định dạng

·         Yêu cầu bị từ chối và gửi lại

·         Người phê duyệt vắng mặt

·         Giao dịch cần xử lý thủ công

·         Hệ thống liên quan tạm thời không khả dụng

·         Một tác vụ cần chuyển sang bộ phận khác

Khả năng xử lý ngoại lệ thường quyết định công nghệ có thực sự vận hành được trong môi trường doanh nghiệp hay chỉ hoạt động tốt trong kịch bản lý tưởng.

Kiểm tra khả năng phù hợp với hệ thống và kiến trúc hiện hữu

Công nghệ không hoạt động độc lập. Nó phải trao đổi dữ liệu, chia sẻ danh tính, tuân thủ kiến trúc và cùng vận hành với nhiều thành phần khác.

ISO/IEC 25010:2023 xem chất lượng sản phẩm ICT theo một mô hình gồm chín đặc tính và các đặc tính con, được sử dụng để xác định cũng như đánh giá yêu cầu chất lượng trong suốt vòng đời sản phẩm. Mô hình áp dụng cho các thành phần ICT như phần mềm, phần cứng, dữ liệu và hạ tầng truyền thông.

Khi đánh giá system fit, doanh nghiệp nên kiểm tra ít nhất bốn nhóm.

Khả năng tích hợp

Cần xác định:

·         Có API hoặc cơ chế trao đổi dữ liệu phù hợp hay không

·         Các định dạng dữ liệu có tương thích không

·         Có hỗ trợ cơ chế xác thực hiện tại không

·         Đồng bộ dữ liệu theo thời gian thực hay theo lô

·         Khi tích hợp lỗi thì phát hiện và khôi phục như thế nào

Không nên dừng ở câu trả lời “có API”. API chỉ có giá trị khi hỗ trợ đúng dữ liệu, đúng thao tác, mức tải, bảo mật và cơ chế vận hành mà doanh nghiệp cần.

Khả năng tương thích dữ liệu

Cần kiểm tra cấu trúc dữ liệu, mã định danh, quy tắc đồng bộ, dữ liệu chủ, chất lượng dữ liệu và quyền sở hữu dữ liệu.

Một dự án có thể gặp khó khăn không phải vì phần mềm thiếu chức năng mà vì dữ liệu giữa các hệ thống không cùng định nghĩa. Ví dụ, cùng một khái niệm “khách hàng” nhưng CRM, ERP và hệ thống thanh toán có thể sử dụng các mã nhận dạng và quy tắc cập nhật khác nhau.

Khả năng đáp ứng kiến trúc và vận hành

Doanh nghiệp cần đánh giá môi trường triển khai, khả năng mở rộng, giám sát, sao lưu, phục hồi, quản trị cấu hình và mức phụ thuộc vào các thành phần khác.

Những yêu cầu này nên được kiểm tra bằng thông số hoặc thử nghiệm thay vì các nhận định như “hiệu năng tốt” hay “khả năng mở rộng cao”.

Rủi ro thay đổi hệ thống liên quan

Một công nghệ cần sửa nhiều hệ thống khác mới có thể hoạt động sẽ tạo ra phạm vi triển khai và rủi ro lớn hơn.

Vì vậy, ngoài chi phí của chính công nghệ, cần ghi nhận:

·         Số tích hợp phải xây dựng mới

·         Hệ thống phải sửa đổi

·         Dữ liệu phải chuyển đổi

·         Quy trình vận hành phải thay đổi

·         Phụ thuộc kỹ thuật mới phát sinh

Đây là phần thường bị bỏ sót nếu doanh nghiệp chỉ so sánh chức năng sản phẩm.

Đánh giá mức độ phù hợp với người dùng

Một hệ thống đáp ứng đúng chức năng nhưng người dùng không thể hoàn thành công việc hiệu quả vẫn chưa đạt mức phù hợp cần thiết.

ISO 9241-11:2018 định nghĩa usability trong mối quan hệ giữa người dùng cụ thể, mục tiêu cụ thể và bối cảnh sử dụng cụ thể, với kết quả được xem xét thông qua effectiveness, efficiency và satisfaction.

ISO/IEC 25019:2023 cũng đặt “context of use” làm điều kiện tiên quyết khi đánh giá chất lượng trong sử dụng; khi bối cảnh sử dụng thay đổi, điều kiện đánh giá cũng cần được xác định lại.

Điều này có nghĩa doanh nghiệp không nên đánh giá trải nghiệm chỉ bằng ý kiến “giao diện dễ dùng”. Cần đưa người dùng đại diện thực hiện những tác vụ thực tế và đo kết quả.

Các chỉ số có thể gồm:

·         Tỷ lệ hoàn thành tác vụ

·         Thời gian hoàn thành

·         Số lỗi trong một tác vụ

·         Số lần phải yêu cầu hỗ trợ

·         Thời gian đào tạo để đạt mức sử dụng cần thiết

·         Mức độ hài lòng của người dùng

·         Tỷ lệ người dùng có thể hoàn thành tác vụ mà không cần hướng dẫn

Giá trị quan trọng nhất không phải một con số chung áp dụng cho mọi doanh nghiệp, mà là sự khác biệt giữa baseline, mục tiêu đã đặt ra và kết quả pilot.

Nếu thời gian thao tác giảm nhưng tỷ lệ lỗi tăng mạnh, không thể kết luận công nghệ phù hợp chỉ từ chỉ số tốc độ. Các metric phải được đọc cùng nhau theo mục tiêu thực tế của tác vụ.

Chấm điểm mức độ phù hợp nhưng không để tổng điểm che lấp rủi ro

Sau khi thu thập bằng chứng, doanh nghiệp có thể dùng ma trận trọng số để tổng hợp kết quả.

Một cách tính thực hành là:

Fit Score = Σ (Trọng số tiêu chí × Điểm đạt được) / Điểm tối đa

Nếu sử dụng thang 1–5 và tổng trọng số bằng 100%, kết quả có thể quy đổi sang thang 100.

Ví dụ:

Các trọng số trên chỉ là ví dụ thiết kế scorecard, không phải benchmark chung của ngành. Doanh nghiệp phải thay đổi trọng số theo mức độ quan trọng của từng yêu cầu.

Một hệ thống phục vụ nghiệp vụ cốt lõi có thể đặt trọng số lớn hơn cho độ tin cậy và tích hợp. Một công cụ được hàng nghìn nhân viên sử dụng hàng ngày có thể cần ưu tiên usability và hiệu quả thao tác.

Sử dụng điều kiện loại song song với điểm số

Scorecard nên có hai tầng:

1.    Gate bắt buộc

2.    Điểm phù hợp có trọng số

Công nghệ chỉ tiếp tục được xem xét khi vượt toàn bộ gate bắt buộc.

Sau đó mới sử dụng điểm số để so sánh mức phù hợp giữa các phương án.

Cách làm này ngăn tình huống một giải pháp đạt điểm cao về chức năng và trải nghiệm nhưng vẫn được chọn dù tồn tại một vấn đề không thể chấp nhận về tích hợp, dữ liệu hoặc yêu cầu kiểm soát bắt buộc.

ISO/IEC 25040:2024 cung cấp một framework để đánh giá chất lượng sản phẩm ICT, dữ liệu và dịch vụ IT theo các yêu cầu và tiêu chí đánh giá xác định trước, thay vì dựa trên nhận xét cảm tính.

Xác nhận bằng pilot trước khi triển khai diện rộng

Đánh giá trên tài liệu chỉ cho biết công nghệ có khả năng phù hợp. Pilot mới cho thấy nó có phù hợp trong điều kiện vận hành thực tế hay không.

Pilot nên sử dụng:

·         Dữ liệu đủ đại diện

·         Người dùng thực tế

·         Quy trình thật hoặc gần với thực tế

·         Các tích hợp quan trọng

·         Khối lượng công việc phù hợp

·         Tình huống ngoại lệ

·         KPI đã xác định từ trước

Trước pilot, cần ghi nhận baseline. Sau pilot, sử dụng cùng định nghĩa KPI để so sánh.

Ví dụ:

Cách trình bày này buộc quyết định dựa trên chênh lệch đo được thay vì những nhận xét như “pilot khá tốt”.

Nếu một KPI không có benchmark chung đáng tin cậy, doanh nghiệp không nên tự tạo ngưỡng ngành. Ngưỡng chấp nhận nên xuất phát từ yêu cầu nghiệp vụ, baseline, mức rủi ro và mục tiêu cải thiện đã xác định trước khi thử nghiệm.

Đánh giá khoảng cách giữa công nghệ và yêu cầu

Kết quả cuối cùng không nên chỉ là một điểm số. Doanh nghiệp cần lập gap analysis cho từng yêu cầu chưa được đáp ứng đầy đủ.

Mỗi khoảng cách nên được phân loại:

Việc công nghệ cần tùy chỉnh không tự động khiến nó không phù hợp. Câu hỏi là mức tùy chỉnh đó có làm mất lợi ích ban đầu hay tạo ra chi phí và rủi ro không hợp lý hay không.

Một giải pháp đáp ứng 90% yêu cầu nhưng 10% còn thiếu nằm ở nghiệp vụ cốt lõi có thể kém phù hợp hơn giải pháp đáp ứng tỷ lệ tổng thể thấp hơn nhưng đáp ứng hoàn toàn các yêu cầu bắt buộc.

Ra quyết định dựa trên bằng chứng tổng hợp

Sau khi hoàn tất đánh giá, doanh nghiệp nên có tối thiểu bốn nhóm bằng chứng:

1.    Requirement matrix cho biết từng yêu cầu được đáp ứng ở mức nào

2.    Process impact cho biết quy trình phải thay đổi ra sao và KPI bị ảnh hưởng thế nào

3.    Technical assessment cho biết khả năng tích hợp, dữ liệu và vận hành

4.    Pilot evidence cho biết người dùng và hệ thống thực tế đạt kết quả nào

Từ đó, quyết định có thể chia thành:

·         Phù hợp: đạt các điều kiện bắt buộc và kết quả thử nghiệm đáp ứng mục tiêu

·         Phù hợp có điều kiện: tồn tại khoảng cách nhưng có phương án xử lý với chi phí và rủi ro chấp nhận được

·         Chưa đủ bằng chứng: cần pilot, kiểm thử hoặc xác minh thêm

·         Không phù hợp: không đạt yêu cầu bắt buộc hoặc khoảng cách lớn hơn giá trị kỳ vọng

Điểm số chỉ là công cụ tổng hợp. Bằng chứng phía sau từng điểm mới là cơ sở của quyết định.

Doanh nghiệp vì vậy nên xem đánh giá mức độ phù hợp công nghệ là quá trình kiểm chứng sự tương thích giữa công nghệ và bối cảnh sử dụng cụ thể. Một công nghệ chỉ thực sự phù hợp khi đáp ứng đúng nhu cầu nghiệp vụ, hoạt động được trong quy trình, kết nối được với hệ thống hiện hữu, cho phép người dùng hoàn thành công việc hiệu quả và vượt qua các điều kiện bắt buộc về vận hành.

Thực hiện đánh giá theo yêu cầu định lượng, gate bắt buộc, ma trận trọng số và pilot giúp doanh nghiệp tránh hai sai lầm phổ biến: chọn công nghệ vì nhiều tính năng và loại công nghệ chỉ vì nó không khớp hoàn toàn với cách vận hành hiện tại. Quyết định tốt hơn là quyết định xác định rõ phần nào phù hợp, phần nào chưa phù hợp, khoảng cách có thể xử lý đến đâu và bằng chứng nào chứng minh điều đó.