Cách nhận diện rủi ro trong thiết kế giải pháp

Cách tiếp cận hiệu quả là lần theo chuỗi:

Mục tiêu → Yêu cầu → Giả định và ràng buộc → Phương án → Giao diện → Công nghệ và dữ liệu → Vận hành → Điều kiện bên ngoài

Mỗi mắt xích đều có thể trở thành nguồn phát sinh rủi ro. Vì vậy, rủi ro trong thiết kế giải pháp cần được nhận diện từ nhiều nguồn thay vì chỉ kiểm tra bản thân thiết kế

Rủi ro trong thiết kế giải pháp nên được nhận diện từ những nguồn nào?

Có thể tập trung vào tám nhóm nguồn chính: yêu cầu, giả định, ràng buộc, kiến trúc và lựa chọn phương án, giao diện, công nghệ và dữ liệu, vận hành, cùng các yếu tố bên ngoài

1. Yêu cầu và kỳ vọng của các bên liên quan

Đây thường là nguồn rủi ro đầu tiên cần kiểm tra. Một thiết kế có thể nhất quán về mặt kỹ thuật nhưng vẫn chứa rủi ro nếu yêu cầu đầu vào không đầy đủ, mâu thuẫn, mơ hồ hoặc không phản ánh đúng nhu cầu thực tế

Cần xem xét:

·         Yêu cầu chức năng có đầy đủ không

·         Yêu cầu hiệu năng có thể kiểm chứng không

·         Các yêu cầu có mâu thuẫn với nhau không

·         Có yêu cầu nào chưa được phân bổ vào thiết kế không

·         Kỳ vọng của người sử dụng có khác với yêu cầu chính thức không

·         Yêu cầu nào phụ thuộc vào giả định chưa được xác nhận

Điểm cần nhận diện không chỉ là “thiết kế có đáp ứng yêu cầu hay không”, mà còn là bản thân yêu cầu có tạo ra rủi ro cho phương án hay không

Ví dụ, một yêu cầu về hiệu năng cao nhưng không đi kèm giới hạn chi phí, tài nguyên hoặc môi trường vận hành có thể khiến nhiều phương án tưởng như khả thi trên giấy nhưng khó triển khai thực tế

2. Giả định và những điều kiện chưa được xác minh

Thiết kế thường phải dựa trên những giả định chưa thể kiểm chứng ngay. Đây là nguồn rủi ro dễ bị bỏ sót vì giả định thường được sử dụng như một dữ kiện đầu vào thay vì được xem là một yếu tố không chắc chắn

Cần lập danh sách các giả định quan trọng như:

·         Điều kiện môi trường sẽ ổn định

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

·         Người dùng sẽ vận hành theo quy trình dự kiến

·         Thành phần phụ thuộc bên ngoài sẽ đáp ứng đúng khả năng đã giả định

·         Công nghệ được lựa chọn sẽ đạt mức hiệu năng dự kiến

·         Nguồn lực và hạ tầng cần thiết sẽ sẵn sàng

Sau đó đặt câu hỏi: Nếu giả định này sai thì phương án bị ảnh hưởng ở đâu?

Một giả định có mức độ ảnh hưởng lớn nhưng chưa được xác minh nên được xem là một điểm rủi ro cần xử lý ngay trong thiết kế

3. Ràng buộc, tiêu chuẩn và điều kiện bắt buộc

Ràng buộc có thể đến từ ngân sách, thời gian, nguồn lực, pháp lý, tiêu chuẩn kỹ thuật, môi trường, an toàn hoặc khả năng tương thích với hệ thống hiện hữu

Rủi ro phát sinh khi thiết kế:

·         Không đáp ứng một ràng buộc bắt buộc

·         Đáp ứng một ràng buộc nhưng làm phát sinh vấn đề ở ràng buộc khác

·         Sử dụng giới hạn kỹ thuật không còn phù hợp

·         Bỏ sót yêu cầu môi trường, an toàn hoặc con người

·         Dựa trên một tiêu chuẩn hoặc phiên bản yêu cầu không còn phù hợp

Vì vậy, việc nhận diện rủi ro phải kiểm tra cả mối quan hệ giữa các ràng buộc, thay vì xem từng ràng buộc độc lập

4. Kiến trúc và các lựa chọn trong chính phương án

Đây là nguồn rủi ro trực tiếp nhất của thiết kế. Mỗi lựa chọn đều tạo ra một tập phụ thuộc và đánh đổi mới

Cần xem xét:

·         Thành phần nào là điểm đơn gây lỗi

·         Phương án phụ thuộc quá nhiều vào một thành phần hay công nghệ

·         Có dư thừa hoặc cơ chế dự phòng cần thiết không

·         Thiết kế có đủ biên an toàn không

·         Một thay đổi ở một thành phần có gây tác động dây chuyền không

·         Có trade-off nào giữa hiệu năng, chi phí, độ phức tạp và độ tin cậy chưa được đánh giá không

Đặc biệt, không nên chỉ hỏi “phương án này có hoạt động không?”. Câu hỏi quan trọng hơn là:

“Phương án này sẽ thất bại theo những cơ chế nào, và điều kiện nào có thể kích hoạt sự thất bại đó?”

Cách đặt câu hỏi này giúp chuyển việc đánh giá từ mô tả thiết kế sang phân tích cơ chế rủi ro

5. Giao diện và các điểm phụ thuộc

Một phương án thường không hoạt động độc lập. Nó phải tương tác với hệ thống, con người, thiết bị, phần mềm, dữ liệu hoặc đơn vị bên ngoài

Giao diện vì vậy là một nguồn rủi ro quan trọng. Cần kiểm tra:

·         Hai bên giao diện có hiểu cùng một yêu cầu không

·         Dữ liệu truyền qua giao diện có đúng định dạng và thời điểm không

·         Trách nhiệm tại ranh giới giữa hai thành phần đã rõ chưa

·         Thay đổi ở một bên có phá vỡ bên còn lại không

·         Các giao diện bên ngoài có được kiểm soát như giao diện nội bộ không

Một thiết kế có thể đạt yêu cầu ở từng thành phần riêng lẻ nhưng vẫn thất bại khi tích hợp nếu giao diện giữa các thành phần không tương thích

6. Công nghệ, dữ liệu và năng lực chưa được chứng minh

Nếu phương án phụ thuộc vào công nghệ mới, công nghệ chưa được kiểm chứng, dữ liệu chưa ổn định hoặc một năng lực kỹ thuật chưa được chứng minh, đó là nguồn rủi ro cần được nhận diện ngay từ thiết kế

Cần đặt câu hỏi:

·         Công nghệ đã đạt mức trưởng thành cần thiết chưa

·         Hiệu năng thực tế đã được kiểm chứng chưa

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

·         Có phụ thuộc vào nhà cung cấp hoặc thành phần độc quyền không

·         Có giới hạn kỹ thuật nào chưa được thử nghiệm không

·         Có khoảng cách giữa thông số lý thuyết và điều kiện vận hành thực tế không

Khi một thuộc tính có thể đo lường, nên dùng thông số kỹ thuật, ngưỡng vận hành, kết quả thử nghiệm, benchmark hoặc dữ liệu nghiên cứu thay cho các mô tả định tính như “cao”, “tốt”, “ổn định” hay “đủ mạnh”

7. Điều kiện vận hành và con người

Một thiết kế không chỉ cần đúng trên bản vẽ mà còn phải phù hợp với cách nó được sử dụng trong thực tế

Nguồn rủi ro có thể nằm ở:

·         Người dùng thao tác khác với giả định thiết kế

·         Quy trình vận hành quá phức tạp

·         Yêu cầu đào tạo vượt quá khả năng thực tế

·         Điều kiện bảo trì không đáp ứng được thiết kế

·         Thiết kế phụ thuộc vào một thao tác thủ công dễ sai

·         Điều kiện môi trường thực tế khác điều kiện thử nghiệm

Do đó, cần kiểm tra rủi ro xuyên suốt vòng đời sử dụng, không dừng ở thời điểm thiết kế hoàn thành

8. Môi trường bên ngoài và các thay đổi có thể xảy ra

Một phương án còn chịu ảnh hưởng bởi những yếu tố nằm ngoài quyền kiểm soát trực tiếp của nhóm thiết kế

Có thể bao gồm:

·         Thay đổi pháp lý hoặc tiêu chuẩn

·         Thay đổi nhà cung cấp

·         Thay đổi hạ tầng

·         Thay đổi nhu cầu người dùng

·         Biến động về chi phí hoặc nguồn lực

·         Điều kiện môi trường

·         Phụ thuộc vào hệ thống hoặc tổ chức bên ngoài

Rủi ro cần được nhận diện không chỉ theo trạng thái hiện tại mà còn theo những thay đổi có khả năng xảy ra trong điều kiện sử dụng dự kiến

Nhận diện rủi ro ở giai đoạn thiết kế nên thực hiện theo trình tự nào?

Không nên bắt đầu bằng việc liệt kê ngẫu nhiên các sự cố. Một trình tự có tính kiểm soát hơn là đi từ mục tiêu đến các yếu tố có thể làm phương án lệch khỏi mục tiêu

Bước 1: Xác định kết quả mà phương án phải đạt

Làm rõ các yêu cầu về chức năng, hiệu năng, chi phí, thời gian, an toàn và các điều kiện quan trọng khác

Bước 2: Truy ngược các giả định và ràng buộc

Với mỗi yêu cầu, xác định phương án đang dựa vào giả định nào và chịu những giới hạn nào

Bước 3: Phân rã phương án

Xem xét từng thành phần, lựa chọn kỹ thuật, phụ thuộc và cơ chế dự phòng để tìm điểm có khả năng gây thất bại

Bước 4: Kiểm tra giao diện

Rà soát cả giao diện nội bộ và bên ngoài, bao gồm giao diện giữa hệ thống, phần mềm, dữ liệu, thiết bị và con người

Bước 5: Kiểm tra điều kiện thực tế

Đưa môi trường, vận hành, bảo trì, năng lực người dùng và các điều kiện bất thường vào phân tích

Bước 6: Đánh giá cơ chế và hậu quả

Không dừng ở câu “có rủi ro”. Cần xác định:

Nguyên nhân → Điều kiện kích hoạt → Sự kiện rủi ro → Hậu quả → Khả năng phát hiện → Cách xử lý

Cấu trúc này giúp phân biệt một rủi ro thực sự với một mối lo chung chung

Làm thế nào để biết một rủi ro đã được nhận diện đủ sâu?

Một rủi ro được nhận diện chưa đủ nếu chỉ có tên gọi như “rủi ro kỹ thuật”, “rủi ro vận hành” hoặc “rủi ro công nghệ”

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

·         Điều gì có thể xảy ra

·         Tại sao có thể xảy ra

·         Điều kiện nào làm rủi ro xuất hiện

·         Phần nào của phương án bị ảnh hưởng

·         Hậu quả là gì

·         Có bằng chứng hoặc dữ liệu nào hỗ trợ đánh giá

·         Giới hạn hoặc ngoại lệ nào cần lưu ý

·         Có biện pháp thiết kế nào làm giảm rủi ro không

Với rủi ro kỹ thuật, nếu có thể lượng hóa thì nên gắn với ngưỡng, chỉ tiêu, xác suất, mức độ ảnh hưởng, dữ liệu thử nghiệm hoặc benchmark phù hợp thay vì chỉ dùng đánh giá “cao” hay “thấp”

Khi nào cần ưu tiên xử lý rủi ro ngay trong thiết kế?

Không phải mọi rủi ro đều phải loại bỏ hoàn toàn. Ưu tiên xử lý những rủi ro có khả năng làm phương án không đạt mục tiêu hoặc khiến chi phí sửa đổi tăng mạnh nếu phát hiện muộn

Đặc biệt cần ưu tiên khi rủi ro:

·         Có hậu quả lớn

·         Khó phát hiện sau khi triển khai

·         Liên quan đến yêu cầu cốt lõi

·         Xuất phát từ kiến trúc hoặc lựa chọn nền tảng

·         Có thể lan truyền sang nhiều thành phần

·         Liên quan đến giao diện quan trọng

·         Phụ thuộc vào giả định chưa được xác minh

·         Có biện pháp giảm thiểu hiệu quả ngay từ thiết kế

Nguyên tắc quan trọng là xử lý rủi ro càng gần nguồn phát sinh càng tốt. Nếu một vấn đề có thể được loại bỏ bằng cách thay đổi thiết kế, thường không nên chỉ dựa vào quy trình vận hành hoặc cảnh báo người dùng để kiểm soát nó

Rủi ro trong thiết kế giải pháp nên được nhận diện từ toàn bộ chuỗi hình thành và vận hành phương án, không chỉ từ bản thiết kế kỹ thuật. Các nguồn quan trọng nhất gồm yêu cầu và kỳ vọng, giả định, ràng buộc, kiến trúc và lựa chọn phương án, giao diện, công nghệ và dữ liệu, điều kiện vận hành, con người và môi trường bên ngoài

Điểm cốt lõi là chuyển từ câu hỏi “Có rủi ro nào?” sang “Thiết kế có thể thất bại ở đâu, vì cơ chế nào, trong điều kiện nào và với hậu quả gì?”. Khi rủi ro được nhận diện theo cách này ngay từ giai đoạn thiết kế, nhóm thực hiện có cơ sở tốt hơn để điều chỉnh phương án trước khi chi phí thay đổi và khắc phục trở nên lớn hơn