Quy trình lựa chọn công nghệ cho doanh nghiệp

Điểm quan trọng là mỗi bước phải tạo ra đầu vào kiểm chứng được cho bước tiếp theo. Nếu yêu cầu ban đầu mơ hồ, bảng điểm phía sau dù chi tiết vẫn có thể dẫn đến lựa chọn sai. Ngược lại, một giải pháp không đứng đầu về số lượng tính năng vẫn có thể là lựa chọn phù hợp nhất nếu đáp ứng tốt các yêu cầu bắt buộc, tích hợp được với hệ thống hiện tại, có mức rủi ro chấp nhận được và tạo ra giá trị kinh doanh rõ ràng.

Bước 1: Xác định vấn đề và kết quả kinh doanh cần đạt

Điểm xuất phát của quá trình lựa chọn phải là vấn đề kinh doanh, không phải danh sách công nghệ đang có trên thị trường. Doanh nghiệp cần mô tả trạng thái hiện tại, nguyên nhân khiến trạng thái đó chưa đạt yêu cầu và kết quả mong muốn sau khi triển khai công nghệ.

Một yêu cầu như “cần một hệ thống CRM tốt hơn” chưa đủ để đánh giá giải pháp. Yêu cầu nên được chuyển thành kết quả quan sát được, chẳng hạn giảm thời gian nhập dữ liệu thủ công, chuẩn hóa quy trình quản lý cơ hội bán hàng, tăng khả năng truy xuất lịch sử tương tác hoặc kết nối dữ liệu bán hàng với hệ thống hiện có.

Ở bước này cần thống nhất ít nhất bốn yếu tố:

·         Vấn đề cần giải quyết

·         Nhóm người dùng và quy trình bị ảnh hưởng

·         Kết quả kinh doanh mong muốn

·         Các ràng buộc không thể bỏ qua như ngân sách, thời gian, pháp lý, dữ liệu hoặc hạ tầng

Nếu chưa thống nhất được bốn yếu tố trên, việc đi thẳng vào xem demo thường khiến nhóm lựa chọn bị dẫn dắt bởi những tính năng nổi bật của nhà cung cấp thay vì nhu cầu thực tế.

Bước 2: Chuyển nhu cầu thành bộ yêu cầu có thể kiểm chứng

Sau khi xác định mục tiêu, doanh nghiệp cần biến nhu cầu thành các yêu cầu đủ cụ thể để có thể kiểm tra một giải pháp là đạt hay không đạt.

Bộ yêu cầu nên phân biệt giữa must-have và nice-to-have. Must-have là điều kiện bắt buộc: nếu không đáp ứng, giải pháp có thể bị loại bất kể tổng điểm ở các tiêu chí khác cao đến đâu. Nice-to-have tạo thêm giá trị nhưng có thể đánh đổi với chi phí, thời gian triển khai hoặc mức độ phức tạp.

Các nhóm yêu cầu thường bao gồm:

·         Chức năng phục vụ quy trình nghiệp vụ

·         Hiệu năng và khả năng mở rộng

·         Tích hợp và khả năng tương tác với hệ thống hiện có

·         Bảo mật và quyền riêng tư

·         Khả năng quản trị, vận hành và giám sát

·         Khả năng cấu hình hoặc tùy biến

·         Trải nghiệm người dùng và khả năng tiếp cận

·         Yêu cầu về dữ liệu, sao lưu, phục hồi và di chuyển dữ liệu

·         Hỗ trợ kỹ thuật và mức dịch vụ

·         Chi phí và điều kiện thương mại

Với sản phẩm ICT hoặc phần mềm, ISO/IEC 25010:2023 có thể được sử dụng như một khung tham chiếu khi xây dựng tiêu chí chất lượng. Tiêu chuẩn này tổ chức chất lượng sản phẩm thành chín đặc tính, gồm functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility và safety. Doanh nghiệp không nhất thiết phải sử dụng toàn bộ; chỉ nên chọn những đặc tính liên quan đến mục tiêu và rủi ro của hệ thống đang xét.

Yêu cầu càng có thể kiểm chứng, quá trình đánh giá càng ít phụ thuộc vào cảm nhận. Thay vì ghi “hệ thống phải nhanh”, có thể đặt điều kiện về thời gian phản hồi trong một kịch bản tải cụ thể. Thay vì “dễ tích hợp”, nên xác định giao diện, giao thức, dữ liệu hoặc hệ thống mà giải pháp phải kết nối.

Bước 3: Xây dựng mô hình đánh giá trước khi xem xét nhà cung cấp

Tiêu chí và trọng số nên được thống nhất trước khi đội ngũ bị ảnh hưởng bởi demo, thương hiệu hoặc đề xuất thương mại của từng nhà cung cấp.

Mô hình đánh giá thường gồm hai lớp. Lớp đầu tiên là điều kiện bắt buộc theo dạng đạt/không đạt. Lớp thứ hai là các tiêu chí có trọng số để phân biệt những giải pháp đã vượt qua vòng bắt buộc.

Ví dụ, với một dự án phần mềm doanh nghiệp, tổ chức có thể phân bổ 100 điểm như sau:

·         30 điểm cho mức độ phù hợp nghiệp vụ

·         20 điểm cho kiến trúc, tích hợp và dữ liệu

·         15 điểm cho bảo mật và tuân thủ

·         15 điểm cho tổng chi phí sở hữu

·         10 điểm cho năng lực nhà cung cấp

·         10 điểm cho khả năng triển khai và vận hành

Đây chỉ là một mô hình minh họa, không phải tỷ lệ chuẩn cho mọi doanh nghiệp. Trọng số phải phản ánh rủi ro và mục tiêu của từng dự án. Một nền tảng xử lý dữ liệu nhạy cảm có thể cần tăng đáng kể trọng số bảo mật; một hệ thống vận hành cốt lõi có thể ưu tiên độ tin cậy và khả năng phục hồi cao hơn chi phí giấy phép.

Cũng cần quy định trước cách chấm điểm. Thang điểm 1–5 chẳng hạn phải có mô tả rõ thế nào là 1, 3 và 5. Nếu không, hai người đánh giá có thể cho cùng một tiêu chí những điểm rất khác nhau dù nhìn vào cùng một bằng chứng.

Bước 4: Khảo sát thị trường và tạo danh sách rút gọn

Chỉ sau khi có bộ yêu cầu và mô hình chấm điểm, doanh nghiệp mới nên khảo sát các giải pháp trên thị trường.

Mục tiêu của giai đoạn này không phải đánh giá toàn diện mọi nhà cung cấp mà là loại nhanh những phương án không phù hợp. Có thể sử dụng tài liệu kỹ thuật, RFI, trao đổi sơ bộ, kiến trúc tham chiếu và thông tin thương mại để kiểm tra các điều kiện nền tảng.

Một giải pháp nên được đưa vào danh sách rút gọn khi có bằng chứng hợp lý rằng nó:

·         Đáp ứng các yêu cầu bắt buộc

·         Phù hợp với kiến trúc và môi trường vận hành

·         Nằm trong phạm vi ngân sách khả thi

·         Có khả năng đáp ứng các yêu cầu về bảo mật và tuân thủ

·         Có nhà cung cấp đủ năng lực hỗ trợ vòng đời dự kiến

Không nên giữ quá nhiều phương án vào vòng đánh giá sâu. Mỗi giải pháp bổ sung làm tăng số lượng demo, tài liệu cần thẩm định, kịch bản thử nghiệm và nguồn lực chuyên môn cần huy động.

Bước 5: Thẩm định kỹ thuật, bảo mật, tài chính và nhà cung cấp

Danh sách rút gọn cần được kiểm tra sâu hơn trước khi tiến hành thử nghiệm tốn nhiều nguồn lực.

Thẩm định mức độ phù hợp kỹ thuật

Đội kỹ thuật cần kiểm tra kiến trúc, mô hình triển khai, API, mô hình dữ liệu, khả năng tích hợp, hiệu năng, khả năng mở rộng, logging, monitoring, backup, recovery và quy trình nâng cấp.

Một tính năng tồn tại trên tài liệu không đồng nghĩa với việc nó phù hợp với môi trường thực tế. Ví dụ, nhà cung cấp có API nhưng API đó có thể không hỗ trợ đúng đối tượng dữ liệu, lưu lượng hoặc cơ chế xác thực mà doanh nghiệp cần.

Thẩm định bảo mật và rủi ro

Bảo mật không nên được xem như một tiêu chí kiểm tra cuối cùng. NIST Cybersecurity Framework 2.0 tổ chức các kết quả quản trị rủi ro an ninh mạng theo sáu chức năng: Govern, Identify, Protect, Detect, Respond và Recover. Cách nhìn này giúp doanh nghiệp đánh giá không chỉ khả năng phòng vệ của công nghệ mà cả quản trị, phát hiện sự cố, ứng phó và phục hồi.

Tùy loại hệ thống, thẩm định có thể bao gồm quản lý danh tính, phân quyền, mã hóa, nhật ký, quản lý lỗ hổng, quy trình ứng phó sự cố, vị trí lưu trữ dữ liệu, nhà thầu phụ và khả năng xuất hoặc xóa dữ liệu.

Thẩm định tổng chi phí sở hữu

Giá giấy phép chỉ là một thành phần của chi phí. Tổng chi phí sở hữu cần xem xét cả triển khai, tích hợp, chuyển đổi dữ liệu, hạ tầng, đào tạo, vận hành, hỗ trợ, tùy biến, nâng cấp và chi phí rời bỏ giải pháp.

Một công nghệ có giá mua thấp nhưng cần nhiều tích hợp riêng hoặc phụ thuộc lớn vào chuyên gia bên ngoài có thể đắt hơn trong toàn bộ vòng đời.

Thẩm định nhà cung cấp

Doanh nghiệp cũng đang lựa chọn một đối tác vận hành, không chỉ lựa chọn sản phẩm. Vì vậy cần đánh giá năng lực hỗ trợ, SLA, lộ trình sản phẩm, mức độ phụ thuộc vào nhà cung cấp, khả năng chuyển dữ liệu, điều khoản chấm dứt và các rủi ro liên quan đến chuỗi cung ứng.

Bước 6: Thử nghiệm bằng kịch bản thực tế và tiêu chí thành công định trước

Demo do nhà cung cấp kiểm soát có giá trị để hiểu sản phẩm nhưng không đủ để xác nhận công nghệ phù hợp với doanh nghiệp. Các phương án cuối cùng nên được kiểm chứng bằng PoC hoặc pilot khi mức độ rủi ro và quy mô đầu tư khiến việc thử nghiệm trở nên cần thiết.

Proof of Concept (PoC) chủ yếu trả lời câu hỏi công nghệ có thể thực hiện một yêu cầu quan trọng hay không. Pilot tiến xa hơn: kiểm tra giải pháp trong phạm vi người dùng, dữ liệu và quy trình gần với vận hành thực tế.

Kịch bản thử nghiệm phải được xây dựng từ yêu cầu ở bước 2. Ví dụ, thay vì yêu cầu nhà cung cấp “trình diễn khả năng tích hợp”, doanh nghiệp có thể yêu cầu đồng bộ một nhóm dữ liệu cụ thể với hệ thống hiện tại, đo thời gian xử lý, kiểm tra lỗi và xác nhận cách phục hồi khi kết nối bị gián đoạn.

Trước khi thử nghiệm cần xác định:

·         Kịch bản cần kiểm chứng

·         Dữ liệu và môi trường thử nghiệm

·         Chỉ số cần đo

·         Tiêu chí đạt hoặc không đạt

·         Người chịu trách nhiệm xác nhận kết quả

·         Các giả định và giới hạn của thử nghiệm

Việc xác định tiêu chí trước giúp tránh tình trạng kết quả PoC được diễn giải lại sau khi biết nhà cung cấp nào thực hiện tốt hơn.

Đối với công nghệ mới hoặc chưa được chứng minh đầy đủ, mức độ trưởng thành cũng là một biến số cần xem xét. Các phương pháp Technology Readiness Assessment của U.S. Government Accountability Office nhấn mạnh việc đánh giá mức độ sẵn sàng của công nghệ trước khi đưa công nghệ chưa đủ trưởng thành vào chương trình hoặc hệ thống, vì mức trưởng thành thấp làm tăng rủi ro về lịch trình và chi phí.

Bước 7: Tổng hợp điểm số, bằng chứng và các trade-off

Sau thử nghiệm, doanh nghiệp có thể cập nhật bảng đánh giá bằng bằng chứng thực tế thay vì tiếp tục dựa chủ yếu vào tài liệu bán hàng.

Tuy nhiên, tổng điểm không nên tự động quyết định phương án thắng. Một hệ thống đạt 88/100 chưa chắc phù hợp hơn hệ thống 84/100 nếu phương án 88 điểm thất bại ở một điều kiện bắt buộc hoặc mang theo một rủi ro mà doanh nghiệp không chấp nhận.

Vì vậy, kết quả đánh giá cần được đọc theo ít nhất bốn lớp:

1.    Điều kiện bắt buộc: Có yêu cầu nào không đạt hay không

2.    Điểm có trọng số: Giải pháp nào tạo mức độ phù hợp tổng thể cao nhất

3.    Rủi ro tồn dư: Những vấn đề nào vẫn còn sau khi áp dụng biện pháp giảm thiểu

4.    Trade-off: Doanh nghiệp đang đánh đổi điều gì để nhận được lợi ích của từng phương án

Một trade-off thường gặp là chọn sản phẩm chuẩn hóa cao nhưng ít tùy biến, hoặc chọn nền tảng linh hoạt hơn nhưng đòi hỏi năng lực kỹ thuật và quản trị lớn hơn. Không có lựa chọn tối ưu tuyệt đối; lựa chọn đúng là phương án có sự đánh đổi phù hợp với mục tiêu và khả năng chịu rủi ro của tổ chức.

Bước 8: Ra quyết định dựa trên bằng chứng và chuẩn bị điều kiện triển khai

Quyết định cuối cùng nên trả lời được ba câu hỏi: tại sao chọn phương án này, bằng chứng nào hỗ trợ quyết định và rủi ro nào doanh nghiệp đã chấp nhận.

Hồ sơ quyết định nên thể hiện tối thiểu:

·         Yêu cầu và mục tiêu ban đầu

·         Danh sách phương án đã đánh giá

·         Kết quả chấm điểm

·         Kết quả PoC hoặc pilot nếu có

·         Tổng chi phí sở hữu

·         Rủi ro và biện pháp giảm thiểu

·         Các trade-off đã chấp nhận

·         Điều kiện thương mại quan trọng

·         Trách nhiệm phê duyệt

Trước khi ký hợp đồng, các giả định quan trọng trong quá trình đánh giá cũng cần được chuyển thành cam kết hoặc tiêu chí nghiệm thu khi phù hợp. Nếu giải pháp được chọn vì một mức dịch vụ, khả năng tích hợp, yêu cầu bảo mật hoặc khả năng di chuyển dữ liệu cụ thể, những yếu tố đó không nên chỉ tồn tại trong slide bán hàng.

Quyết định mua công nghệ cũng chưa phải điểm kết thúc. Doanh nghiệp chỉ nên chuyển sang triển khai khi đã xác định chủ sở hữu hệ thống, nguồn lực triển khai, kế hoạch tích hợp và chuyển đổi dữ liệu, tiêu chí nghiệm thu, mô hình hỗ trợ và cơ chế đo kết quả kinh doanh sau khi đưa hệ thống vào sử dụng.

Một quy trình lựa chọn công nghệ hiệu quả tạo ra chuỗi bằng chứng từ nhu cầu đến quyết định: vấn đề kinh doanh xác định yêu cầu; yêu cầu xác định tiêu chí; tiêu chí dẫn đến danh sách rút gọn; thẩm định và thử nghiệm tạo bằng chứng; bằng chứng cuối cùng hỗ trợ quyết định.

Doanh nghiệp vì thế không nên lựa chọn dựa trên giải pháp có nhiều tính năng nhất hay giá chào thấp nhất. Phương án phù hợp hơn là phương án đáp ứng các yêu cầu bắt buộc, tạo giá trị đối với mục tiêu kinh doanh, vận hành được trong kiến trúc hiện tại, có tổng chi phí sở hữu chấp nhận được và mang mức rủi ro mà tổ chức có thể quản trị.

Có nhất thiết phải thực hiện PoC khi lựa chọn công nghệ không?

Không phải mọi quyết định đều cần PoC. Với công nghệ phổ biến, phạm vi nhỏ và rủi ro thấp, tài liệu kỹ thuật, reference check và demo theo kịch bản có thể đủ. PoC có giá trị hơn khi tồn tại giả định kỹ thuật quan trọng chưa được chứng minh, mức đầu tư lớn hoặc thất bại có ảnh hưởng đáng kể đến hoạt động.

Nên chấm điểm công nghệ trước hay sau khi demo?

Tiêu chí, trọng số và cách chấm nên được thống nhất trước demo. Điểm có thể được cập nhật sau demo, thẩm định và thử nghiệm khi có thêm bằng chứng. Cách này giảm nguy cơ đội đánh giá thay đổi tiêu chí để phù hợp với sản phẩm gây ấn tượng mạnh nhất.

Giải pháp có tổng điểm cao nhất có phải luôn là lựa chọn tốt nhất không?

Không. Tổng điểm chỉ có ý nghĩa sau khi giải pháp vượt qua các điều kiện bắt buộc. Một phương án có điểm cao nhưng không đáp ứng yêu cầu pháp lý, bảo mật, tích hợp hoặc một ràng buộc trọng yếu vẫn có thể phải bị loại.

Chi phí nào cần tính ngoài giá bản quyền hoặc thuê bao?

Cần xem xét toàn bộ chi phí liên quan đến triển khai, tích hợp, chuyển đổi dữ liệu, hạ tầng, đào tạo, vận hành, hỗ trợ, tùy biến, nâng cấp và khả năng rời bỏ giải pháp. Đây là lý do tổng chi phí sở hữu thường hữu ích hơn giá mua ban đầu khi so sánh các phương án.