Lựa chọn công nghệ doanh nghiệp là gì và dựa trên đâu?

Điểm quan trọng nằm ở khái niệm phù hợp, không phải “mới nhất”, “mạnh nhất” hay có nhiều tính năng nhất. Một công nghệ chỉ tạo giá trị khi đáp ứng được yêu cầu cần giải quyết với mức chi phí, rủi ro, khả năng vận hành và khả năng phát triển mà doanh nghiệp có thể chấp nhận.

Vì vậy, quyết định hợp lý thường phải đi qua chuỗi logic:

Yêu cầu → tiêu chí → điều kiện bắt buộc → phương án → bằng chứng so sánh → rủi ro và chi phí → kiểm chứng → quyết định

Cách tiếp cận này biến lựa chọn công nghệ từ một quyết định dựa nhiều vào cảm nhận thành một bài toán có thể giải thích, đo lường và kiểm chứng.

Lựa chọn công nghệ doanh nghiệp thực chất là lựa chọn mức độ phù hợp

Hai doanh nghiệp có cùng nhu cầu chức năng vẫn có thể chọn hai công nghệ khác nhau mà cả hai quyết định đều hợp lý. Nguyên nhân là công nghệ không hoạt động độc lập; nó phải tồn tại trong một hệ thống gồm con người, quy trình, dữ liệu, ngân sách, hạ tầng hiện hữu và các giới hạn quản trị.

Ví dụ, một nền tảng có khả năng mở rộng rất lớn chưa chắc là lựa chọn tốt cho doanh nghiệp có tải ổn định nhưng đội kỹ thuật nhỏ. Lợi ích về scalability có thể không bù được chi phí vận hành và độ phức tạp mà nền tảng tạo thêm.

Ngược lại, giải pháp tương đối đơn giản ở thời điểm hiện tại có thể trở nên không phù hợp nếu doanh nghiệp dự kiến tăng mạnh lượng giao dịch, số người dùng hoặc phạm vi tích hợp trong vài năm tới.

Do đó, câu hỏi đúng không phải:

“Công nghệ nào tốt nhất?”

mà là:

“Công nghệ nào đáp ứng tốt nhất các yêu cầu quan trọng của doanh nghiệp với tổng chi phí và mức rủi ro có thể chấp nhận?”

Mức phù hợp phải được đánh giá trong một bối cảnh xác định. Khi mục tiêu, quy mô, nguồn lực hoặc giới hạn thay đổi, kết quả lựa chọn cũng có thể thay đổi.

Yêu cầu kinh doanh phải được chuyển thành yêu cầu công nghệ trước khi so sánh

Một trong những nguyên nhân làm quá trình lựa chọn sai hướng là bắt đầu bằng danh sách sản phẩm hoặc nhà cung cấp thay vì bắt đầu từ vấn đề cần giải quyết.

Yêu cầu ban đầu của doanh nghiệp thường được mô tả dưới dạng mục tiêu kinh doanh như giảm thời gian xử lý, phục vụ thêm khách hàng, giảm thao tác thủ công, hỗ trợ làm việc đa chi nhánh hoặc nâng cao khả năng kiểm soát dữ liệu. Những mục tiêu này chưa đủ cụ thể để đánh giá công nghệ.

Chúng cần được chuyển thành các yêu cầu có thể kiểm tra.

Chẳng hạn, yêu cầu “hệ thống phải nhanh” chưa tạo được tiêu chuẩn lựa chọn. Doanh nghiệp cần xác định nhanh trong tác vụ nào, với bao nhiêu người dùng, khối lượng dữ liệu nào và mức phản hồi chấp nhận được là bao nhiêu.

Tương tự, “hệ thống phải ổn định” có thể được chuyển thành các yêu cầu về availability, thời gian phục hồi, khả năng dự phòng hoặc mức mất dữ liệu cho phép.

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

Không phải yêu cầu nào cũng có giá trị ngang nhau.

Yêu cầu bắt buộc là điều kiện mà một phương án phải đáp ứng để được tiếp tục xem xét. Đó có thể là khả năng tích hợp với hệ thống hiện hữu, yêu cầu lưu trữ dữ liệu, quyền kiểm soát truy cập hoặc một giới hạn ngân sách.

Nếu một phương án vi phạm điều kiện bắt buộc, điểm mạnh ở các tiêu chí khác thường không thể bù lại.

Yêu cầu ưu tiên dùng để phân biệt các phương án đã vượt qua điều kiện bắt buộc. Ví dụ, doanh nghiệp có thể ưu tiên khả năng triển khai nhanh, chi phí vận hành thấp hoặc dễ tìm nhân sự có kỹ năng phù hợp.

Sự phân biệt này ngăn tình trạng một công nghệ đạt tổng điểm cao nhưng vẫn không đáp ứng một điều kiện thiết yếu của doanh nghiệp.

Những tiêu chí nào cần dùng để đánh giá công nghệ?

Bộ tiêu chí phải được xây dựng từ yêu cầu thực tế thay vì áp dụng máy móc một checklist cho mọi doanh nghiệp. Tuy nhiên, một quyết định công nghệ cấp doanh nghiệp thường cần xem xét đồng thời một số nhóm tiêu chí cốt lõi.

Khả năng đáp ứng chức năng và quy trình

Trước hết, công nghệ phải thực hiện được những chức năng mà quy trình kinh doanh thực sự cần.

Cần phân biệt giữa tính năng “có tồn tại” và tính năng “đáp ứng được cách doanh nghiệp vận hành”. Một chức năng chỉ có giá trị khi có thể áp dụng trong luồng nghiệp vụ thực tế với mức tùy biến hợp lý.

Nếu phần lớn quy trình quan trọng phải được sửa đổi chỉ để phù hợp với giới hạn của công nghệ, doanh nghiệp cần đánh giá xem đó là cải tiến quy trình hay chỉ là chi phí thích nghi phát sinh từ lựa chọn không phù hợp.

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

Hiệu năng nên được xác định bằng những đại lượng có thể đo như thời gian phản hồi, throughput, số người dùng đồng thời, số giao dịch hoặc lượng dữ liệu xử lý.

Thay vì yêu cầu chung chung “hiệu năng cao”, doanh nghiệp có thể đặt một ngưỡng cụ thể cho workload của mình, chẳng hạn thời gian phản hồi p95 không vượt quá mức đã xác định ở một tác vụ quan trọng. Đây là ngưỡng yêu cầu của doanh nghiệp, không phải benchmark phổ quát cho mọi hệ thống.

Khả năng mở rộng cũng cần gắn với dự báo tải. Một kiến trúc có thể scale tới quy mô rất lớn không tự động tạo lợi thế nếu doanh nghiệp không có khả năng sử dụng mức mở rộng đó.

Khả năng tích hợp và tương thích

Công nghệ mới hiếm khi hoạt động một mình. Nó phải trao đổi dữ liệu hoặc chức năng với ERP, CRM, hệ thống tài chính, nền tảng dữ liệu, dịch vụ xác thực hay các ứng dụng nội bộ khác.

Cần kiểm tra API, giao thức, định dạng dữ liệu, cơ chế xác thực, khả năng đồng bộ, giới hạn tốc độ, khả năng xử lý lỗi và công cụ tích hợp hiện có.

Một sản phẩm có chức năng tốt nhưng khó tích hợp có thể tạo chi phí lớn trong suốt vòng đời sử dụng.

Chất lượng và khả năng bảo trì

Đối với sản phẩm ICT và phần mềm, ISO/IEC 25010:2023 cung cấp một mô hình tham chiếu gồm chín đặc tính chất lượng để hỗ trợ việc xác định, đo lường và đánh giá chất lượng sản phẩm.

Trong quyết định thực tế, doanh nghiệp cần quan tâm đến các đặc tính liên quan trực tiếp tới workload và môi trường của mình, chẳng hạn reliability, performance efficiency, maintainability, compatibility hoặc security, thay vì cố gắng tối ưu mọi đặc tính đồng thời.

Khả năng bảo trì đặc biệt quan trọng với công nghệ có vòng đời dài. Một giải pháp khó nâng cấp, khó quan sát lỗi hoặc phụ thuộc nhiều vào kiến thức riêng của một số cá nhân có thể tạo ra chi phí kỹ thuật lớn về sau.

An toàn thông tin và quản trị rủi ro

Đánh giá bảo mật không nên chỉ dừng ở việc hỏi một sản phẩm “có an toàn không”.

NIST Cybersecurity Framework 2.0 tổ chức quản trị rủi ro an ninh mạng quanh sáu nhóm chức năng: Govern, Identify, Protect, Detect, Respond và Recover. Tư duy này cho thấy doanh nghiệp cần xem xét cả quản trị, phòng vệ, phát hiện, phản ứng và phục hồi thay vì chỉ tập trung vào tính năng bảo vệ.

Tùy loại công nghệ, các tiêu chí có thể bao gồm:

·         Cơ chế xác thực và phân quyền

·         Mã hóa dữ liệu khi lưu trữ và truyền tải

·         Audit log và khả năng truy vết

·         Quản lý lỗ hổng và bản vá

·         Sao lưu và phục hồi

·         Phân tách dữ liệu

·         Khả năng ứng phó sự cố

·         Quản trị nhà cung cấp và chuỗi cung ứng

Công nghệ có nhiều tính năng bảo mật vẫn có thể không phù hợp nếu doanh nghiệp không đủ khả năng cấu hình và vận hành chúng đúng cách.

Khả năng vận hành và năng lực đội ngũ

Công nghệ cần được đánh giá cùng với những người sẽ triển khai, vận hành và bảo trì nó.

Nếu một phương án đòi hỏi chuyên môn mà doanh nghiệp chưa có, cần tính cả thời gian tuyển dụng, đào tạo, thuê đối tác hoặc xây dựng năng lực nội bộ.

Đây cũng là lý do một kiến trúc đơn giản hơn đôi khi mang lại giá trị thực tế cao hơn kiến trúc tiên tiến nhưng vượt xa khả năng vận hành của tổ chức.

Không nên so sánh công nghệ chỉ bằng giá mua ban đầu

Chi phí của công nghệ tồn tại trong toàn bộ vòng đời sử dụng. Vì vậy, giá license hoặc chi phí triển khai ban đầu chỉ là một phần của quyết định.

Một cách đánh giá thực tế hơn là Total Cost of Ownership – TCO.

Tùy loại công nghệ, TCO có thể bao gồm:

TCO = chi phí mua hoặc thuê triển khai hạ tầng tích hợp migration vận hành nhân sự đào tạo hỗ trợ nâng cấp bảo mật chi phí thoát khỏi công nghệ

Đối với hệ thống cloud, đơn vị chi phí cũng nên gắn với giá trị kinh doanh khi có thể. Thay vì chỉ theo dõi tổng hóa đơn hạ tầng, doanh nghiệp có thể xem chi phí trên mỗi giao dịch, mỗi khách hàng, mỗi đơn hàng hoặc một đơn vị nghiệp vụ phù hợp.

Điều này đặc biệt hữu ích khi hai phương án có mô hình chi phí khác nhau. Một giải pháp có chi phí cố định cao nhưng unit cost giảm khi quy mô tăng có thể phù hợp với trường hợp khác với một dịch vụ có chi phí khởi đầu thấp nhưng tăng gần tuyến tính theo lượng sử dụng.

Chi phí chuyển đổi cũng là một phần của quyết định

Một công nghệ có thể hấp dẫn trong giai đoạn triển khai nhưng rất khó rời bỏ sau đó.

Doanh nghiệp cần kiểm tra:

·         Dữ liệu có thể xuất ra ở định dạng sử dụng được hay không

·         API hoặc giao thức có mang tính độc quyền hay không

·         Ứng dụng phụ thuộc bao nhiêu vào dịch vụ riêng của nhà cung cấp

·         Chi phí migration sang phương án khác

·         Điều khoản khi chấm dứt dịch vụ

·         Khả năng tiếp tục vận hành khi nhà cung cấp thay đổi sản phẩm

Vendor lock-in không phải lúc nào cũng cần tránh hoàn toàn. Việc sử dụng một dịch vụ độc quyền có thể mang lại tốc độ triển khai hoặc hiệu quả đáng kể. Vấn đề là lợi ích đó có lớn hơn chi phí chuyển đổi và rủi ro phụ thuộc hay không.

So sánh các phương án bằng ma trận tiêu chí có trọng số

Khi có nhiều lựa chọn tương đối giống nhau, doanh nghiệp có thể dùng weighted decision matrix để làm rõ logic ra quyết định.

Mỗi tiêu chí được gán một trọng số theo mức quan trọng. Sau đó mỗi phương án được chấm theo cùng một thang điểm và cùng một bộ bằng chứng.

Điểm tổng có thể tính theo:

Điểm phương án = Σ (trọng số tiêu chí × điểm tiêu chí)

Ví dụ, doanh nghiệp có thể phân bổ trọng số:

Các tỷ lệ trên chỉ là ví dụ minh họa. Trọng số đúng phải phản ánh mục tiêu của doanh nghiệp.

Nếu bảo mật là điều kiện sống còn, nó có thể được chuyển thành tiêu chí bắt buộc thay vì chỉ tăng trọng số. Tương tự, nếu doanh nghiệp cần triển khai trong ba tháng, khả năng đáp ứng thời hạn có thể trở thành điều kiện loại trực tiếp.

Ma trận giúp minh bạch hóa lựa chọn nhưng không thay thế tư duy chuyên môn. Một con số tổng hợp chỉ có ý nghĩa khi tiêu chí, trọng số và dữ liệu đầu vào hợp lý.

Bằng chứng nào nên được dùng khi đánh giá công nghệ?

Một quyết định công nghệ đáng tin cậy cần phân biệt giữa thông tin marketing và bằng chứng có thể kiểm tra.

Tài liệu của nhà cung cấp có ích để xác định tính năng và thông số được công bố, nhưng không nên là nguồn duy nhất cho các kết luận quan trọng về hiệu năng, khả năng vận hành hoặc mức phù hợp.

Doanh nghiệp có thể kết hợp nhiều dạng bằng chứng:

·         Technical specification và tài liệu kiến trúc

·         Tiêu chuẩn hoặc framework phù hợp với lĩnh vực

·         Benchmark thực hiện trên workload đại diện

·         Kết quả Proof of Concept

·         Dữ liệu vận hành thử nghiệm

·         Hồ sơ bảo mật và compliance

·         Điều khoản SLA và hỗ trợ

·         Case thực tế có điều kiện tương đồng

·         Phỏng vấn đội triển khai và vận hành

·         Chi phí được mô phỏng theo tải dự kiến

Bằng chứng càng gần môi trường thực tế của doanh nghiệp thì giá trị ra quyết định càng cao.

Một benchmark trên cấu hình phần cứng khác, tập dữ liệu khác hoặc pattern truy cập khác có thể chính xác về mặt kỹ thuật nhưng không trả lời được hệ thống sẽ hoạt động thế nào trong workload thực tế.

Proof of Concept giúp kiểm chứng giả định trước khi cam kết

PoC đặc biệt hữu ích khi tồn tại những câu hỏi quan trọng mà tài liệu và demo không giải quyết đủ chắc chắn.

PoC không cần mô phỏng toàn bộ hệ thống. Nó nên tập trung vào những giả định có rủi ro cao nhất.

Ví dụ, nếu lo ngại chính là khả năng tích hợp, PoC nên kiểm tra luồng tích hợp khó nhất thay vì dành phần lớn thời gian xây giao diện đẹp.

Nếu điểm chưa chắc chắn là hiệu năng, cần sử dụng workload và volume dữ liệu đại diện để đo latency, throughput hoặc khả năng scale.

Một PoC tốt cần có tiêu chí PASS/FAIL được xác định trước khi thử nghiệm. Nếu tiêu chí được thay đổi sau khi đã thấy kết quả, thử nghiệm rất dễ trở thành quá trình hợp thức hóa một phương án đã được yêu thích từ trước.

Với công nghệ có tác động lớn, doanh nghiệp có thể đi tiếp từ PoC sang pilot giới hạn trước khi triển khai toàn diện. Pilot bổ sung những bằng chứng mà thử nghiệm kỹ thuật khó tạo ra, như khả năng sử dụng, hỗ trợ vận hành, quy trình xử lý sự cố và mức thích nghi của người dùng.

Những trade-off nào thường xuất hiện khi chọn công nghệ?

Hiếm có phương án nào tối ưu đồng thời mọi tiêu chí. Lựa chọn công nghệ vì vậy thường là quá trình quản lý trade-off.

Tính năng phong phú và độ phức tạp

Nhiều chức năng tạo khả năng đáp ứng nhiều tình huống hơn nhưng cũng có thể làm tăng độ phức tạp cấu hình, vận hành và đào tạo.

Nếu doanh nghiệp chỉ sử dụng một phần nhỏ khả năng của nền tảng, phần còn lại không tạo giá trị nhưng chi phí phức tạp vẫn tồn tại.

Kiểm soát và tốc độ triển khai

Tự quản lý hạ tầng hoặc phần mềm thường cho doanh nghiệp mức kiểm soát cao hơn. Dịch vụ được quản lý có thể giảm công việc vận hành và rút ngắn thời gian triển khai nhưng làm tăng mức phụ thuộc vào nhà cung cấp.

Không có lựa chọn đúng tuyệt đối; doanh nghiệp cần xác định loại kiểm soát nào thực sự tạo giá trị.

Chuẩn hóa và tùy biến

Chuẩn hóa giúp hệ thống dễ quản trị hơn, trong khi tùy biến có thể đáp ứng tốt hơn những quy trình đặc thù.

Tùy biến quá sâu thường làm tăng chi phí nâng cấp và bảo trì. Ngược lại, ép một quy trình có giá trị cạnh tranh vào một giải pháp quá cứng nhắc cũng có thể làm mất lợi thế nghiệp vụ.

Tối ưu hiện tại và khả năng phát triển

Một công nghệ có thể rất hiệu quả với workload hiện tại nhưng tạo giới hạn lớn khi quy mô hoặc mô hình kinh doanh thay đổi.

Tuy nhiên, thiết kế quá xa cho tương lai cũng có chi phí. Doanh nghiệp không cần mua trước mọi khả năng có thể cần; cần xác định đâu là thay đổi có xác suất và tác động đủ lớn để được đưa vào quyết định hiện tại.

Quy trình đánh giá công nghệ nên diễn ra như thế nào?

Một quy trình có kiểm soát có thể được tổ chức thành tám bước.

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

Nêu rõ vấn đề hiện tại, người chịu tác động và kết quả mong muốn. Tránh bắt đầu bằng tên một sản phẩm đã được ưu tiên trước.

2. Chuyển mục tiêu thành yêu cầu đo được

Xác định chức năng, tích hợp, hiệu năng, dữ liệu, bảo mật, khả năng phục hồi, vận hành và các giới hạn cần thiết.

3. Tách điều kiện bắt buộc khỏi tiêu chí ưu tiên

Loại sớm những phương án không đáp ứng các constraint không thể thương lượng.

4. Xác định tiêu chí và trọng số

Trọng số phải phản ánh giá trị và rủi ro đối với doanh nghiệp, không phản ánh mức độ nổi tiếng của công nghệ.

5. Thu thập bằng chứng theo cùng một chuẩn

Mọi phương án nên được đánh giá trên cùng loại dữ liệu để tránh so sánh tài liệu marketing của một nhà cung cấp với benchmark thực nghiệm của nhà cung cấp khác.

6. Phân tích TCO, rủi ro và trade-off

Không chỉ hỏi phương án đạt được gì mà còn phải xác định doanh nghiệp phải chấp nhận điều gì để đạt được lợi ích đó.

7. Kiểm chứng những giả định quan trọng

Dùng PoC, benchmark hoặc pilot cho các điểm có mức bất định và tác động cao.

8. Ghi lại rationale của quyết định

Kết quả cuối cùng nên nêu được phương án được chọn, điều kiện làm nó phù hợp, trade-off đã chấp nhận và những giả định cần tiếp tục theo dõi.

Rationale rất quan trọng vì quyết định công nghệ có vòng đời. Khi chi phí, tải, kiến trúc hoặc mục tiêu kinh doanh thay đổi, doanh nghiệp có thể xem lại liệu các giả định ban đầu còn đúng hay không.

Khi nào một công nghệ được xem là phù hợp với doanh nghiệp?

Một công nghệ có thể được xem là phù hợp khi đồng thời đáp ứng bốn điều kiện chính.

Thứ nhất, nó vượt qua toàn bộ yêu cầu bắt buộc.

Thứ hai, bằng chứng cho thấy nó đạt mức yêu cầu ở những tiêu chí tạo giá trị chính.

Thứ ba, tổng chi phí, rủi ro và trade-off nằm trong giới hạn doanh nghiệp chấp nhận.

Thứ tư, doanh nghiệp có khả năng triển khai và vận hành công nghệ đó trong thực tế.

Điều kiện cuối cùng thường bị xem nhẹ. Một nền tảng mạnh trên giấy nhưng không có đội ngũ, quy trình hoặc ngân sách để vận hành đúng cách không phải phương án phù hợp chỉ vì điểm kỹ thuật cao.

Vì thế, “phù hợp” là giao điểm giữa giá trị kinh doanh, chất lượng kỹ thuật, tính khả thi vận hành, chi phí và rủi ro.

Lựa chọn công nghệ doanh nghiệp là một quá trình đánh giá có điều kiện, không phải cuộc thi tìm sản phẩm có nhiều tính năng hay công nghệ tiên tiến nhất. Doanh nghiệp cần bắt đầu từ vấn đề và yêu cầu, chuyển yêu cầu thành tiêu chí có thể kiểm tra, loại các phương án vi phạm điều kiện bắt buộc rồi so sánh những lựa chọn còn lại bằng bằng chứng, TCO, rủi ro và trade-off.

Khi mức bất định còn cao, PoC hoặc pilot giúp kiểm chứng các giả định quan trọng trước khi cam kết quy mô lớn. Phương án đáng chọn cuối cùng là phương án chứng minh được rằng nó đáp ứng yêu cầu quan trọng với tổng chi phí và rủi ro chấp nhận được, đồng thời phù hợp với năng lực vận hành và hướng phát triển thực tế của doanh nghiệp.