Tiêu chí lựa chọn công nghệ doanh nghiệp phù hợp

Vì vậy, quá trình lựa chọn nên bắt đầu bằng yêu cầu kinh doanh có thể kiểm chứng, sau đó mới chuyển sang so sánh giải pháp. Ba câu hỏi cần được trả lời xuyên suốt là: công nghệ có đáp ứng nhu cầu trọng yếu không, có vận hành được trong hệ sinh thái hiện có không và tổng giá trị nhận được có tương xứng với toàn bộ chi phí cùng rủi ro phát sinh không.

Xác định nhu cầu kinh doanh trước khi so sánh giải pháp

Sai lệch phổ biến trong lựa chọn công nghệ doanh nghiệp là bắt đầu bằng danh sách sản phẩm rồi mới tìm lý do để sử dụng chúng. Cách tiếp cận này dễ khiến doanh nghiệp đánh giá theo số lượng tính năng thay vì mức độ giải quyết vấn đề.

Điểm xuất phát nên là một nhu cầu kinh doanh cụ thể. Thay vì đặt yêu cầu chung như “cần một hệ thống quản lý tốt hơn”, doanh nghiệp cần xác định vấn đề đang xảy ra, đối tượng bị ảnh hưởng và kết quả cần cải thiện. Ví dụ, nếu quy trình phê duyệt hợp đồng đang mất trung bình ba ngày, mục tiêu của dự án có thể là rút ngắn thời gian xử lý, giảm thao tác thủ công và tạo lịch sử phê duyệt có thể truy vết.

Từ mục tiêu đó, yêu cầu công nghệ có thể được chia thành ba mức:

·         Bắt buộc: Thiếu tiêu chí này thì giải pháp không thể đáp ứng bài toán cốt lõi

·         Quan trọng: Có ảnh hưởng lớn đến hiệu quả triển khai nhưng vẫn có thể xử lý bằng quy trình hoặc cấu hình bổ sung

·         Mong muốn: Tạo thêm tiện ích nhưng không quyết định thành công của dự án

Phân loại như vậy giúp tránh tình trạng một sản phẩm được chấm điểm cao nhờ hàng chục chức năng phụ trong khi thiếu một chức năng bắt buộc.

Yêu cầu cũng cần gắn với chỉ số có thể đo. Nếu mục tiêu kinh doanh là giảm 20% thời gian xử lý đơn hàng, quá trình đánh giá phải kiểm tra trực tiếp khả năng đạt mức cải thiện đó. Nhận xét như “giao diện hiện đại” hoặc “tự động hóa tốt” không thể thay thế chỉ số liên quan tới kết quả cần đạt.

Một yêu cầu chỉ nên được đưa vào tiêu chí lựa chọn khi doanh nghiệp có thể giải thích nó phục vụ quy trình, người dùng hoặc mục tiêu kinh doanh nào. Đây là bộ lọc đầu tiên giúp thu hẹp danh sách giải pháp trước khi đánh giá sâu hơn.

Đánh giá khả năng tích hợp với hệ thống và dữ liệu hiện có

Một công nghệ có thể hoạt động tốt khi đứng riêng nhưng trở nên tốn kém khi đưa vào môi trường doanh nghiệp. Nguyên nhân nằm ở các phụ thuộc giữa ứng dụng, dữ liệu, danh tính người dùng, quy trình và hạ tầng.

Do đó, khả năng tích hợp không nên được kiểm tra bằng câu hỏi đơn giản “có API hay không”. Doanh nghiệp cần xác định API hoặc cơ chế kết nối đó có thực sự đáp ứng luồng dữ liệu cần triển khai hay không.

Với từng hệ thống cần kết nối, nên làm rõ:

·         Dữ liệu nào phải được trao đổi

·         Luồng dữ liệu một chiều hay hai chiều

·         Cần xử lý theo thời gian thực hay theo lô

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

·         Cách xử lý bản ghi trùng, lỗi đồng bộ và thay đổi cấu trúc dữ liệu

·         Hạn mức giao dịch hoặc giới hạn kỹ thuật có ảnh hưởng đến tải thực tế hay không

Điểm quan trọng là đánh giá cả cơ chế khi tích hợp thất bại. Một kết nối chỉ được xem là vận hành được khi doanh nghiệp biết lỗi được phát hiện như thế nào, dữ liệu có thể gửi lại hay không và ai chịu trách nhiệm xử lý.

Khả năng tương thích với dữ liệu cũng cần được xem riêng. Nếu triển khai giải pháp mới đòi hỏi làm sạch, chuyển đổi hoặc ánh xạ khối lượng lớn dữ liệu lịch sử, chi phí thực tế có thể cao hơn đáng kể so với chi phí phần mềm. Đối với hệ thống đã vận hành nhiều năm, chất lượng dữ liệu đôi khi là rào cản lớn hơn bản thân công nghệ.

Doanh nghiệp cũng nên kiểm tra mức phụ thuộc vào thành phần độc quyền. Nếu một quy trình quan trọng chỉ có thể hoạt động thông qua định dạng, giao diện hoặc công cụ riêng của nhà cung cấp, chi phí thay đổi trong tương lai sẽ tăng. Tích hợp tốt vì thế không chỉ có nghĩa là kết nối được hôm nay mà còn bao gồm khả năng duy trì và thay đổi kết nối khi kiến trúc doanh nghiệp phát triển.

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

Giá license hoặc phí thuê bao chỉ phản ánh một phần chi phí công nghệ. Hai giải pháp có giá niêm yết tương đương có thể tạo ra tổng chi phí rất khác nhau sau khi tính triển khai, tích hợp, vận hành và thay đổi.

Tổng chi phí sở hữu nên được xem trong toàn bộ khoảng thời gian doanh nghiệp dự kiến sử dụng giải pháp. Các nhóm chi phí cần tính thường gồm:

·         Phí license, thuê bao hoặc tài nguyên sử dụng

·         Chi phí triển khai và cấu hình

·         Chi phí tích hợp

·         Chi phí di chuyển và làm sạch dữ liệu

·         Hạ tầng hoặc thiết bị bổ sung

·         Đào tạo người dùng

·         Nhân sự vận hành và quản trị

·         Hỗ trợ kỹ thuật

·         Nâng cấp và mở rộng

·         Chi phí chấm dứt hợp đồng, xuất dữ liệu hoặc chuyển sang nền tảng khác

Chi phí phải được đánh giá cùng mô hình sử dụng. Chẳng hạn, một giải pháp tính phí theo người dùng có thể hợp lý ở quy mô hiện tại nhưng tăng nhanh khi số lượng nhân viên sử dụng tăng. Một nền tảng tính theo giao dịch lại có thể tạo cấu trúc chi phí khác khi lưu lượng kinh doanh biến động.

Vì vậy, doanh nghiệp nên mô phỏng ít nhất kịch bản sử dụng hiện tại và kịch bản tăng trưởng dự kiến. Mục tiêu không phải dự đoán chính xác từng khoản chi trong nhiều năm, mà là xác định yếu tố nào làm chi phí biến động và mức độ nhạy cảm của tổng ngân sách đối với yếu tố đó.

Chi phí cũng cần được đặt cạnh giá trị tạo ra. Một giải pháp đắt hơn vẫn có thể hợp lý nếu giảm đủ chi phí nhân công, giảm lỗi hoặc cải thiện năng lực xử lý. Ngược lại, giá mua thấp không tạo lợi thế nếu doanh nghiệp phải duy trì nhiều thao tác thủ công hoặc xây dựng thêm một lớp tích hợp phức tạp.

Cách so sánh hữu ích hơn là xem xét chi phí cho một đơn vị giá trị, chẳng hạn chi phí trên mỗi giao dịch được xử lý, mỗi người dùng hoạt động hoặc mỗi quy trình được tự động hóa. Khi đó, quyết định công nghệ được liên kết trực tiếp với hiệu quả kinh doanh thay vì chỉ với ngân sách mua sắm.

Kiểm tra khả năng mở rộng, bảo mật và năng lực vận hành

Một giải pháp đáp ứng quy mô hiện tại chưa chắc đáp ứng được doanh nghiệp sau vài năm. Khả năng mở rộng vì thế phải được đánh giá theo những yếu tố thực sự tạo tải cho hệ thống như số người dùng đồng thời, lượng giao dịch, dung lượng dữ liệu hoặc số đơn vị kinh doanh.

Không nên chấp nhận mô tả chung rằng một nền tảng “có khả năng mở rộng”. Nhà cung cấp cần chứng minh giới hạn hoặc cách hệ thống xử lý tải tương ứng với kịch bản của doanh nghiệp. Nếu hoạt động kinh doanh có mùa cao điểm, việc đánh giá phải bao gồm chính mức tải cao điểm thay vì chỉ sử dụng số liệu trung bình.

Bảo mật cũng không nên được coi là một mục kiểm tra tách biệt ở cuối dự án. Một công nghệ mới có thể tạo thêm tài khoản đặc quyền, điểm tích hợp, kho dữ liệu hoặc nhà cung cấp có quyền truy cập vào thông tin doanh nghiệp. Mỗi thành phần đều làm thay đổi bề mặt rủi ro.

Các yêu cầu cần được xác định theo dữ liệu và quy trình thực tế, chẳng hạn:

·         Cơ chế xác thực và quản lý quyền truy cập

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

·         Nhật ký hoạt động và khả năng truy vết

·         Sao lưu và khôi phục

·         Quản lý lỗ hổng và cập nhật bảo mật

·         Vị trí lưu trữ dữ liệu nếu có yêu cầu liên quan

·         Cách nhà cung cấp xử lý và thông báo sự cố

Doanh nghiệp cần yêu cầu bằng chứng tương ứng với mức rủi ro, chẳng hạn tài liệu kỹ thuật, kết quả đánh giá độc lập, chứng nhận phù hợp hoặc điều khoản hợp đồng. Việc nhà cung cấp tuyên bố sản phẩm “an toàn” không đủ để xác lập mức độ phù hợp.

Năng lực vận hành nội bộ cũng là một giới hạn quan trọng. Một nền tảng rất linh hoạt nhưng cần đội ngũ chuyên môn mà doanh nghiệp không có có thể làm tăng thời gian triển khai và phụ thuộc vào dịch vụ bên ngoài. Vì vậy, cần đánh giá ai sẽ cấu hình, giám sát, xử lý lỗi và nâng cấp hệ thống sau khi dự án kết thúc.

Đánh giá nhà cung cấp và rủi ro phụ thuộc dài hạn

Doanh nghiệp không chỉ lựa chọn sản phẩm mà còn lựa chọn một mối quan hệ vận hành. Khi công nghệ trở thành một phần của quy trình quan trọng, năng lực của nhà cung cấp ảnh hưởng trực tiếp đến khả năng duy trì hệ thống.

Đánh giá nhà cung cấp nên tập trung vào các yếu tố có thể kiểm chứng: năng lực hỗ trợ, cam kết dịch vụ, lịch sử phát triển sản phẩm, tài liệu kỹ thuật, cơ chế thông báo thay đổi và khả năng hỗ trợ khi xảy ra sự cố.

Điều khoản dịch vụ cần được đọc theo tình huống vận hành thay vì chỉ kiểm tra xem hợp đồng có SLA hay không. Chẳng hạn, cần xác định rõ thế nào được coi là sự cố nghiêm trọng, thời gian phản hồi khác gì thời gian khôi phục và các thành phần tích hợp có nằm trong phạm vi hỗ trợ hay không.

Rủi ro phụ thuộc nhà cung cấp đặc biệt quan trọng khi công nghệ nắm giữ dữ liệu hoặc quy trình cốt lõi. Doanh nghiệp nên biết ngay từ trước:

·         Có thể xuất dữ liệu ở định dạng nào

·         Việc chuyển dữ liệu sang hệ thống khác khó đến mức nào

·         Các tùy chỉnh có thể tái sử dụng hay phải xây dựng lại

·         Điều gì xảy ra khi ngừng sử dụng dịch vụ

·         Chi phí và thời gian cần thiết để chuyển đổi nền tảng

Vendor lock-in không phải lúc nào cũng cần loại bỏ hoàn toàn. Một giải pháp tích hợp sâu có thể tạo hiệu quả lớn hơn dù chi phí chuyển đổi cao hơn. Vấn đề là doanh nghiệp phải nhìn thấy trade-off đó trước khi ký hợp đồng thay vì chỉ phát hiện khi muốn thay đổi hệ thống.

Vì thế, đánh giá nhà cung cấp nên trả lời hai câu hỏi khác nhau: nhà cung cấp có đủ khả năng hỗ trợ doanh nghiệp trong thời gian dự kiến sử dụng công nghệ không, và doanh nghiệp có phương án khả thi nếu quan hệ đó cần kết thúc không.

Chấm điểm và thử nghiệm trước khi ra quyết định

Khi đã xác định yêu cầu và rủi ro, doanh nghiệp cần một cơ chế so sánh giúp hạn chế việc ra quyết định dựa trên ấn tượng từ bản trình diễn sản phẩm.

Một ma trận chấm điểm có trọng số là cách đơn giản để liên kết quyết định với mức độ quan trọng của từng tiêu chí. Ví dụ, một doanh nghiệp có thể phân bổ trọng số như sau:

·         Mức đáp ứng nhu cầu kinh doanh: 30%

·         Khả năng tích hợp: 20%

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

·         Bảo mật và độ tin cậy: 15%

·         Khả năng mở rộng và vận hành: 10%

·         Rủi ro nhà cung cấp: 5%

Đây chỉ là ví dụ về cơ chế chấm điểm, không phải tỷ trọng chuẩn cho mọi doanh nghiệp. Nếu dự án xử lý dữ liệu nhạy cảm, trọng số bảo mật có thể lớn hơn. Nếu mục tiêu chính là thay thế một hệ thống có hàng chục kết nối, khả năng tích hợp có thể trở thành tiêu chí quan trọng nhất.

Mỗi tiêu chí có thể được chấm trên cùng một thang điểm, chẳng hạn từ 1 đến 5, sau đó nhân với trọng số. Tuy nhiên, điểm tổng không nên được dùng để bù trừ cho yêu cầu bắt buộc. Một giải pháp đạt điểm rất cao ở các tiêu chí khác vẫn phải bị loại nếu không đáp ứng một điều kiện không thể thỏa hiệp, chẳng hạn yêu cầu về dữ liệu, bảo mật hoặc chức năng cốt lõi.

Trước quyết định cuối cùng, các giả định quan trọng nên được kiểm chứng bằng proof of concept hoặc pilot. Bản demo do nhà cung cấp chuẩn bị thường cho thấy kịch bản thuận lợi nhất; pilot phải dùng dữ liệu, quy trình và điều kiện gần với môi trường thật của doanh nghiệp.

Tiêu chí thành công của pilot cần được xác định trước. Nếu mục tiêu dự án là giảm 20% thời gian xử lý một nghiệp vụ, thử nghiệm phải đo thời gian trước và sau. Nếu rủi ro chính nằm ở tích hợp, pilot cần thực hiện luồng dữ liệu thực tế và kiểm tra cả tình huống lỗi.

Kết quả thử nghiệm nên được ghi lại cùng các vấn đề còn mở, chi phí xử lý và người chịu trách nhiệm. Nhờ đó, quyết định cuối cùng dựa trên bằng chứng về khả năng vận hành thay vì lời hứa về khả năng của sản phẩm.

Lựa chọn công nghệ doanh nghiệp phù hợp là bài toán về mức độ phù hợp, không phải cuộc thi tìm sản phẩm có nhiều tính năng nhất. Một quyết định có cơ sở phải nối được nhu cầu kinh doanh với yêu cầu kỹ thuật, kiểm tra khả năng tích hợp trong môi trường thực tế, tính toàn bộ chi phí sở hữu và nhìn rõ những rủi ro xuất hiện trong quá trình vận hành.

Trước khi cam kết đầu tư, doanh nghiệp nên xác định các tiêu chí bắt buộc, thiết lập trọng số cho các tiêu chí còn lại và kiểm chứng những giả định quan trọng bằng dữ liệu hoặc thử nghiệm thực tế. Khi các tiêu chí, bằng chứng và điều kiện loại trừ được xác định trước, quá trình lựa chọn sẽ ít phụ thuộc hơn vào cảm tính, thương hiệu hoặc một bản demo hấp dẫn.