Cách kiểm tra tính khả thi của giải pháp

Điểm quan trọng là phân biệt khả năng lý thuyết với khả năng triển khai. Một giải pháp có thể hoạt động tốt trong điều kiện thử nghiệm nhưng vẫn không khả thi nếu phụ thuộc vào năng lực mà tổ chức chưa có, cần quá nhiều nguồn lực hoặc làm phát sinh quy trình vận hành khó duy trì. Vì vậy, việc lựa chọn chỉ nên diễn ra sau khi các giả định quan trọng đã được kiểm chứng bằng dữ liệu, thử nghiệm hoặc bằng chứng thực tế phù hợp.

Xác định điều kiện để một giải pháp được xem là khả thi

Trước khi đánh giá từng phương án, cần xác định rõ “khả thi” có nghĩa là gì đối với vấn đề đang giải quyết. Nếu không có điều kiện đánh giá từ đầu, nhóm ra quyết định rất dễ chuyển sang so sánh bằng cảm nhận hoặc ưu tiên phương án hấp dẫn nhất về mặt ý tưởng.

Một giải pháp khả thi thường phải vượt qua ba nhóm điều kiện cốt lõi:

·         Kỹ thuật: Có thể đáp ứng các yêu cầu chức năng, hiệu năng, chất lượng, tương thích và giới hạn kỹ thuật bắt buộc

·         Nguồn lực: Có đủ con người, thời gian, ngân sách, công cụ, dữ liệu, hạ tầng hoặc năng lực chuyên môn để triển khai

·         Vận hành: Có thể tích hợp vào quy trình thực tế, được sử dụng đúng cách, kiểm soát được lỗi và duy trì sau khi triển khai

Các tiêu chí này không nên được xem như ba điểm cộng bù trừ cho nhau. Nếu một điều kiện là bắt buộc, việc đạt điểm cao ở hai nhóm còn lại không thể bù cho việc thất bại ở điều kiện đó. Chẳng hạn, một phương án rất rẻ và dễ vận hành vẫn không thể được chọn nếu không đáp ứng yêu cầu kỹ thuật tối thiểu.

Vì thế, nên tách tiêu chí thành hai loại. Điều kiện bắt buộc là những yêu cầu không đạt thì phương án bị loại hoặc phải điều chỉnh. Tiêu chí ưu tiên dùng để so sánh các phương án đã vượt qua điều kiện bắt buộc. Cách phân chia này giúp tránh tình trạng một điểm tổng hợp cao che khuất một điểm yếu có thể làm dự án thất bại.

Kiểm tra tính khả thi về kỹ thuật

Khả thi về kỹ thuật trả lời câu hỏi: giải pháp có thực sự thực hiện được chức năng cần thiết trong môi trường dự kiến hay không.

Đối chiếu với yêu cầu kỹ thuật bắt buộc

Trước hết phải chuyển mục tiêu chung thành yêu cầu có thể kiểm tra. Tùy loại giải pháp, các yêu cầu có thể liên quan đến:

·         Chức năng phải thực hiện

·         Công suất hoặc hiệu năng cần đạt

·         Độ chính xác và chất lượng đầu ra

·         Khả năng tương thích với hệ thống hiện tại

·         Khả năng tích hợp dữ liệu hoặc thiết bị

·         Điều kiện môi trường hoạt động

·         Yêu cầu an toàn, bảo mật hoặc độ tin cậy

·         Khả năng mở rộng khi tải hoặc quy mô tăng

Mỗi yêu cầu quan trọng cần có cách xác minh tương ứng. Nếu yêu cầu là tốc độ xử lý, phải đo tốc độ. Nếu vấn đề nằm ở khả năng tích hợp, cần thử tích hợp. Nếu rủi ro nằm ở tải cao, phải kiểm tra trong điều kiện tải gần với thực tế. Một nhận định như “công nghệ này đủ mạnh” không phải bằng chứng về tính khả thi nếu chưa gắn với yêu cầu cụ thể.

Kiểm tra các phụ thuộc và điểm nghẽn

Nhiều phương án thất bại không phải vì thành phần trung tâm không hoạt động mà vì một phụ thuộc bên ngoài không đáp ứng được. Do đó cần kiểm tra cả chuỗi điều kiện để giải pháp hoạt động, chẳng hạn:

·         Hạ tầng có đáp ứng được yêu cầu không

·         Hệ thống hiện hữu có giao tiếp được với giải pháp mới không

·         Dữ liệu đầu vào có đủ chất lượng không

·         Có phụ thuộc vào công nghệ hoặc nhà cung cấp mà tổ chức không kiểm soát không

·         Một thành phần hỏng có làm toàn bộ phương án ngừng hoạt động không

Điểm cần tìm là ràng buộc quyết định tính khả thi, không phải liệt kê toàn bộ đặc tính kỹ thuật. Nếu một phụ thuộc chưa thể kiểm chứng, kết luận phù hợp là “chưa đủ bằng chứng”, thay vì tự động xem phương án là khả thi.

Dùng thử nghiệm để thay thế giả định

Với các yếu tố kỹ thuật còn bất định, mô hình thử nghiệm nhỏ, prototype hoặc proof of concept có giá trị hơn tranh luận lý thuyết. Thử nghiệm nên tập trung vào giả định có khả năng làm thay đổi quyết định nhất.

Ví dụ, nếu phương án chỉ khả thi khi một hệ thống mới có thể trao đổi dữ liệu ổn định với hệ thống cũ, thử nghiệm nên kiểm chứng chính giao diện tích hợp đó. Không cần xây toàn bộ giải pháp trước khi biết nút thắt quan trọng nhất có vượt qua được hay không.

Một thử nghiệm kỹ thuật có ý nghĩa khi đã xác định trước tiêu chí đạt, dữ liệu cần thu thập và điều kiện thử. Nếu chỉ chạy thử rồi đánh giá bằng cảm giác “có vẻ ổn”, phần bất định ban đầu vẫn chưa thực sự được loại bỏ.

Kiểm tra nguồn lực có đủ để triển khai hay không

Một giải pháp có thể đúng về kỹ thuật nhưng vẫn không khả thi khi tổ chức không có đủ năng lực để thực hiện nó. Vì vậy, đánh giá nguồn lực phải xem xét cả số lượng, khả năng sẵn sàng và mức độ phù hợp của nguồn lực.

Kiểm tra con người và năng lực chuyên môn

Không nên chỉ hỏi có bao nhiêu người. Cần xác định những vai trò nào thực sự cần thiết, mỗi vai trò cần kỹ năng gì và nguồn lực đó có thể tham gia vào đúng thời điểm hay không.

Các câu hỏi quan trọng gồm:

·         Có đủ người sở hữu năng lực chuyên môn cần thiết không

·         Năng lực đó đã có nội bộ hay phải thuê ngoài

·         Người phụ trách có đủ thời gian thực tế để tham gia không

·         Có phụ thuộc quá nhiều vào một cá nhân chủ chốt không

·         Sau triển khai, ai đủ năng lực để duy trì và xử lý sự cố

Một chuyên gia “có trong tổ chức” nhưng không thể dành nguồn lực cho phương án không nên được tính là năng lực sẵn có. Tương tự, kỹ năng có thể đào tạo trong tương lai cần được xem là một điều kiện cần hoàn thành, không phải năng lực đã tồn tại.

Kiểm tra thời gian và khả năng huy động

Thời gian không chỉ là ngày hoàn thành dự kiến. Cần xem xét các công việc phụ thuộc, thời gian chờ, đào tạo, kiểm thử, phê duyệt và chuyển đổi sang vận hành.

Một kế hoạch khả thi phải phản ánh năng lực thực tế của nguồn lực. Nếu cùng một nhóm đang được phân bổ cho nhiều nhiệm vụ, việc tính toàn bộ công suất của nhóm cho phương án mới sẽ tạo ra năng lực ảo.

Do đó, cần so sánh:

Khối lượng công việc cần thực hiện → năng lực thực tế có thể huy động → khoảng thiếu hụt → khả năng bổ sung

Khoảng thiếu hụt có thể được giải quyết bằng tăng nhân lực, giảm phạm vi, thay đổi cách triển khai hoặc kéo dài tiến độ. Nếu không có cách xử lý hợp lý, đó là bằng chứng phương án chưa khả thi trong điều kiện hiện tại.

Kiểm tra ngân sách, công cụ và các nguồn lực hỗ trợ

Chi phí cần được nhìn theo toàn bộ vòng triển khai cần thiết cho quyết định hiện tại, không chỉ theo khoản đầu tư ban đầu. Một phương án có thể cần thêm chi phí cho tích hợp, đào tạo, chuyển đổi dữ liệu, kiểm thử, hỗ trợ hoặc duy trì.

Tương tự, công cụ và hạ tầng cũng cần được xác minh về khả năng tiếp cận thực tế. Việc một loại thiết bị, phần mềm hoặc dữ liệu tồn tại trên thị trường không đồng nghĩa với việc tổ chức có thể sử dụng nó đúng thời điểm và trong điều kiện yêu cầu.

Nếu chi phí hoặc nguồn lực vẫn có độ bất định lớn, nên thể hiện dưới dạng khoảng và kịch bản thay vì một con số duy nhất có độ chính xác giả tạo.

Đánh giá khả năng vận hành sau khi triển khai

Khả thi về vận hành trả lời một câu hỏi khác với kỹ thuật: ngay cả khi giải pháp hoạt động, tổ chức có thể sử dụng và duy trì nó trong công việc hằng ngày hay không.

Kiểm tra mức độ phù hợp với quy trình thực tế

Một giải pháp mới thường làm thay đổi cách thông tin, công việc hoặc trách nhiệm di chuyển giữa các bộ phận. Cần xác định:

·         Bước nào trong quy trình hiện tại sẽ thay đổi

·         Ai phải thực hiện thao tác mới

·         Quyền hạn hoặc trách nhiệm có thay đổi không

·         Có phát sinh bước kiểm tra, nhập liệu hoặc phê duyệt mới không

·         Giải pháp có tạo thêm điểm chờ hoặc thao tác thủ công không

Một phương án có thể tối ưu một bước nhưng làm tăng khối lượng công việc ở bước khác. Vì vậy, đánh giá phải theo luồng vận hành từ đầu đến cuối chứ không chỉ tại nơi giải pháp trực tiếp được áp dụng.

Xác định người sở hữu và cơ chế xử lý sự cố

Giải pháp chưa thực sự sẵn sàng vận hành nếu chưa trả lời được những câu hỏi như: ai chịu trách nhiệm, ai giám sát, khi xảy ra lỗi thì xử lý thế nào và khi điều kiện thay đổi thì ai được quyền điều chỉnh.

Ít nhất cần làm rõ:

·         Chủ sở hữu vận hành

·         Người sử dụng trực tiếp

·         Cơ chế giám sát kết quả

·         Cách phát hiện và xử lý sai lệch

·         Phương án hỗ trợ khi có sự cố

·         Trách nhiệm duy trì sau giai đoạn triển khai

Thiếu các vai trò này thường không làm giải pháp thất bại ngay trong thử nghiệm, nhưng có thể khiến hiệu quả suy giảm sau khi chuyển sang vận hành chính thức.

Kiểm tra khả năng duy trì chứ không chỉ khả năng khởi động

Một lỗi phổ biến là đánh giá tính khả thi dựa trên việc “có thể triển khai được một lần”. Điều cần kiểm tra thêm là giải pháp có thể lặp lại ổn định với nguồn lực bình thường hay chỉ hoạt động khi có sự hỗ trợ đặc biệt của nhóm dự án.

Nếu mỗi lần vận hành đều cần chuyên gia can thiệp, xử lý ngoại lệ thủ công hoặc sử dụng nguồn lực vượt mức bình thường, phương án có thể phù hợp với thử nghiệm nhưng chưa chắc phù hợp với vận hành lâu dài.

Chuyển các giả định thành thử nghiệm trước khi lựa chọn

Ba nhóm đánh giá trên chỉ có giá trị khi những điểm chưa chắc chắn được biến thành câu hỏi có thể kiểm chứng. Đây là bước giúp chuyển từ “đánh giá trên giấy” sang bằng chứng thực tế.

Trước tiên, hãy liệt kê những giả định mà phương án buộc phải đúng mới có thể thành công. Sau đó, ưu tiên kiểm chứng các giả định vừa có mức bất định cao vừa có hậu quả lớn nếu sai.

Có thể dùng trình tự:

1.    Xác định điều kiện bắt buộc để giải pháp hoạt động

2.    Xác định giả định chưa có bằng chứng

3.    Chọn giả định có khả năng làm thay đổi quyết định

4.    Thiết kế thử nghiệm nhỏ nhất có thể kiểm chứng giả định đó

5.    Xác định trước tiêu chí đạt và không đạt

6.    Thu thập kết quả trong điều kiện gần với thực tế

7.    Cập nhật đánh giá khả thi dựa trên bằng chứng

Không phải mọi rủi ro đều cần một pilot hoàn chỉnh. Có vấn đề chỉ cần kiểm tra dữ liệu, xác nhận năng lực nguồn lực hoặc thử một điểm tích hợp. Nguyên tắc là sử dụng phép kiểm tra nhỏ nhất nhưng đủ mạnh để giảm bất định có ý nghĩa.

Ví dụ, nếu một giải pháp đòi hỏi nhân viên hoàn thành một thao tác mới trong quy trình hằng ngày, thử nghiệm không chỉ cần chứng minh chức năng hoạt động. Cần quan sát thời gian thực hiện, tỷ lệ thao tác đúng, lỗi phát sinh và mức hỗ trợ cần thiết. Những dữ liệu này đồng thời kiểm chứng tính kỹ thuật, tải nguồn lực và khả năng vận hành.

Ra quyết định theo điều kiện đạt, đạt có điều kiện hoặc không đạt

Kết quả kiểm tra tính khả thi không nhất thiết chỉ là “chọn” hoặc “loại”. Việc chia kết quả thành ba trạng thái giúp phản ánh đúng mức độ bằng chứng.

Đạt nghĩa là các điều kiện bắt buộc đã được kiểm chứng và không còn khoảng trống quan trọng có khả năng làm thay đổi quyết định.

Đạt có điều kiện nghĩa là phương án có thể triển khai nếu một số điều kiện cụ thể được xử lý trước, chẳng hạn bổ sung năng lực, hoàn thiện tích hợp hoặc thay đổi quy trình.

Không đạt nghĩa là tồn tại một ràng buộc bắt buộc mà phương án không đáp ứng được hoặc chi phí để khắc phục làm mất ý nghĩa của phương án.

Khi có nhiều phương án cùng đạt điều kiện bắt buộc, lúc đó mới nên dùng các tiêu chí ưu tiên để so sánh, chẳng hạn lượng nguồn lực cần huy động, mức phức tạp vận hành, độ linh hoạt hoặc mức bất định còn lại.

Không nên biến điểm tổng hợp thành cơ chế thay thế phán đoán. Một bảng chấm điểm có thể hỗ trợ so sánh, nhưng trước đó vẫn cần áp dụng các “cổng” bắt buộc. Nếu phương án không vượt qua một yêu cầu không thể thỏa hiệp, điểm cao ở các tiêu chí khác không làm nó khả thi hơn.

Việc kiểm tra tính khả thi của giải pháp vì thế nên được xem như quá trình giảm bất định trước khi cam kết nguồn lực. Trình tự hiệu quả là xác định điều kiện bắt buộc, kiểm tra kỹ thuật, xác minh nguồn lực, mô phỏng vận hành rồi thử nghiệm những giả định quan trọng nhất. Chỉ khi bằng chứng cho thấy phương án có thể hoạt động trong điều kiện thực tế và các khoảng thiếu hụt đều có cách xử lý rõ ràng, việc lựa chọn mới có cơ sở vững chắc.