Nhận dạng rủi ro là gì? Cơ sở và phương pháp nhận dạng rủi ro?
Nhận dạng rủi ro là việc phát hiện được các rủi ro xuất hiện trong quá trình thực hiện các quá trình. Vậy quy định về nhận dạng rủi ro là gì, sơ sở và phương pháp nhận dạng rủi ro được quy định như thế nào.
Mục lục bài viết
1. Nhận dạng rủi ro là gì?
– Khái niệm nhận dạng rủi ro:
Nhận dạng rủi ro có thể được gọi tốt hơn là phát hiện và làm sáng tỏ rủi ro. Mục tiêu chính là tìm kiếm và xác định bất kỳ và tất cả các rủi ro có thể tồn tại. Để giữ cho quá trình không bị kết thúc hoàn toàn mở, “bước xác định” là xác định quan điểm chính và ranh giới bối cảnh của phân tích rủi ro tổng thể. Về cơ bản, điều này xác định ai đang thực hiện phân tích (ví dụ: người quản lý dự án CNTT) và những vấn đề nào thuộc lĩnh vực trách nhiệm của người đó. Bất kỳ điều gì nằm ngoài ranh giới này phải được coi là một phần trong các giả định của dự án, tức là các rủi ro mà hậu quả của nó đang được chấp nhận. Việc ràng buộc chính xác phân tích là rất khó và là nguồn sai sót lớn nhất trong bất kỳ phân tích nào (Rescher, 1983).
Để hỗ trợ cho việc xác định ranh giới bối cảnh và viễn cảnh, thông thường bạn phải lập một danh sách đầy đủ các mục tiêu, giả định, kỳ vọng và ràng buộc của dự án, sau đó kiểm tra xem có hợp lý không. Nếu các mục tiêu không hợp lý, thì quy trình quản lý rủi ro tốt nhất trên thế giới sẽ không giúp ích được gì. Tương tự, nếu các giả định không chính xác, khả năng thành công của dự án sẽ bằng không, nếu không có nhiều may mắn. Nếu các ràng buộc quá chặt chẽ, một lần nữa, thành công sẽ khó đạt được.
Thông thường, các mục tiêu được liệt kê theo thứ tự ưu tiên như một biện pháp hỗ trợ cho bất kỳ sự đánh đổi nào trong quản lý rủi ro có thể phải thực hiện sau này — các mục tiêu cấp thấp có thể được đánh đổi theo mức độ rủi ro. Tuy nhiên, điều này ngụ ý rằng một mức rủi ro được coi là (không) chấp nhận được đã được xác định. Mức độ chấp nhận được, được gọi là tham chiếu rủi ro dự án, là điểm mà tại đó dự án đã được xác định không nên tiến hành thêm nữa nếu không có quyết định chính thức để tiếp tục, sửa đổi dự án hoặc dừng dự án. Trên thực tế, tham chiếu rủi ro của dự án thay đổi theo thời gian, khá lỏng lẻo khi bắt đầu dự án, sau đó trở nên chặt chẽ hơn khi dự án tiến hành. Các rủi ro riêng lẻ, khi đã được xác định, cũng sẽ có các tham chiếu rủi ro đi kèm với chúng để chỉ ra khi nào chúng cũng không thể chấp nhận được.
Xác định các tham chiếu rủi ro có thể đo lường được có lẽ là hoạt động quan trọng nhất nhưng cũng khó nhất để thực hiện, cũng như hoạt động thường bị bỏ qua nhất trong thực tế. Không có cách nào dễ dàng để kết hợp các rủi ro riêng lẻ thành một rủi ro cấp dự án duy nhất hoặc ngược lại (Moore, 1983), mặc dù việc có được các mục tiêu thành công và thất bại có thể đo lường được có thể giúp ích rất nhiều. Định nghĩa kém về khả năng chấp nhận rủi ro có thể dẫn đến việc chấp nhận mức độ rủi ro không xác đáng hoặc không xác định, như đã xảy ra trong sự cố Challenger (NAP, 1988). Tiêu chí phóng cho thời tiết lạnh không được xác định trước rõ ràng, mặc dù người ta biết rằng thời tiết lạnh có khả năng cao là một số bộ phận của tàu vũ trụ sẽ không hoạt động như thiết kế.
2. Cơ sở và phương pháp nhận dạng rủi ro:
Khi xác định rủi ro dự án liên quan đến CNTT, cần phải kiểm tra ít nhất bốn loại rủi ro: rủi ro quy trình, rủi ro sản phẩm, rủi ro tổ chức và rủi ro kinh doanh (Charette, 1990). Rủi ro quy trình là những rủi ro liên quan đến các quy trình đang được sử dụng để quản lý, thu nhận, thiết kế, phát triển, thử nghiệm, vận hành và / hoặc phát triển hệ thống CNTT. Chất lượng của hệ thống CNTT phụ thuộc nhiều vào các quy trình được sử dụng để phát triển nó. Các quy trình thiếu hoặc không phù hợp có thể ảnh hưởng đến dự án.
Rủi ro sản phẩm là những rủi ro liên quan đến kiến trúc và triển khai vật lý của hệ thống CNTT. Các vấn đề về kiến trúc liên quan đến thiết kế tổng thể của chính hệ thống CNTT (ví dụ: độ phức tạp về không gian / thời gian có cân bằng không, số lượng giao diện đủ hay quá nhiều, giao thức giao diện có chính xác không), trong khi vấn đề triển khai liên quan đến việc liệu phần cứng thực sự được sử dụng có đủ tin cậy hay không, hệ điều hành đang được sử dụng có phù hợp không, giao diện con người có phù hợp với trình độ kỹ năng của người vận hành hay không, v.v.
Rủi ro tổ chức liên quan đến các vấn đề rủi ro “mềm”: tổ chức có đủ số lượng nhân sự đủ năng lực không, cơ cấu tổ chức có hiệu quả không và nó có giúp thúc đẩy giao tiếp rủi ro không, có quá nhiều cấp chính trị tham gia vào dự án, v.v.
Rủi ro kinh doanh liên quan đến các vấn đề kinh doanh và tài chính làm nền tảng cho dự án, ví dụ, khả năng cạnh tranh, năng suất, các mối quan tâm về hợp đồng, quy định và pháp lý hoặc đạo đức. Rủi ro kinh doanh cũng liên quan đến các vấn đề thị trường, chẳng hạn như các mối quan tâm liên quan đến khách hàng.
Các chiến lược xác định rủi ro có phạm vi khá rộng, sử dụng các kỹ thuật tìm kiếm từ trên xuống cũng như từ dưới lên. Cùng với các phương pháp tiếp cận phổ biến nhất của động não và sử dụng danh sách kiểm tra, các phương pháp tiếp cận quản lý chất lượng như sơ đồ phân tích nguyên nhân gốc rễ và triển khai chức năng chất lượng (QFD) (Ross, 1988; Wilson và cộng sự, 1993) thường được sử dụng, cũng như phân tích các kịch bản giả định mô tả các tình huống mà các rủi ro khác nhau có thể xảy ra (Schwartz, 1991).
Một phương pháp ngày càng phổ biến là sử dụng “phân loại rủi ro” cung cấp danh sách các rủi ro thường gặp được hỗ trợ bởi bảng câu hỏi (Charette, 1989, 1990). Viện Kỹ thuật Phần mềm (SEI) đã phát triển một phân loại định hướng dự án phần mềm phân loại rủi ro thành ba loại chính (Carr và cộng sự, 1993): kỹ thuật sản phẩm, môi trường phát triển và các ràng buộc của chương trình. Các lớp này được chia nhỏ thành các phần tử: ví dụ: kỹ thuật sản phẩm được chia thành các yêu cầu, thiết kế, mã và kiểm tra đơn vị, tích hợp và kiểm tra, và các chuyên ngành kỹ thuật. Mỗi yếu tố này lại được chia thành các thuộc tính: ví dụ: các yêu cầu được chia thành độ ổn định, tính đầy đủ, rõ ràng, v.v.
Ý tưởng là để một nhà phân tích rủi ro sử dụng phương pháp phân loại để tìm kiếm các nguồn phổ biến nhất của rủi ro dự án phần mềm một cách nhanh chóng, có thể lặp lại và có thể đo lường được bằng cách hỏi các thành viên dự án một tập hợp các câu hỏi chung — ví dụ, các yêu cầu của dự án có ổn định không, đầy đủ, rõ ràng, v.v. Từ các câu trả lời nhận được, hồ sơ về rủi ro của dự án có thể được thu thập và nắm bắt để đánh giá, quản lý và theo dõi lịch sử sau này. Viện Công nghệ Phần mềm đã chính thức hóa cách tiếp cận phân loại của họ thành một thứ gọi là quản lý rủi ro nhóm, tập trung vào việc đưa vào quy trình góc nhìn của khách hàng về những rủi ro liên quan (Higuera và cộng sự, 1994).
Phân loại SEI không phải là phương pháp duy nhất có sẵn. Jones (1994) cũng liệt kê các rủi ro khác nhau liên quan đến CNTT cùng với các nguyên nhân có thể xảy ra của chúng, Boehm (1989) và Không quân Hoa Kỳ (AFSC, 1988) cũng vậy.
Các phương pháp tiếp cận phân loại rất hữu ích vì chúng dễ sử dụng và dễ hiểu đối với hầu hết các thành viên dự án. Tuy nhiên, cần phải thận trọng khi phụ thuộc vào việc xác định rủi ro dựa trên phân loại là phương tiện nhận dạng chính, vì các phương pháp tiếp cận như vậy thường bị giới hạn về phạm vi, đặc biệt nếu chúng không được cập nhật liên tục để phản ánh những thay đổi trong công nghệ hoặc cạnh tranh. Các cơ quan phân loại cũng có xu hướng kiểm tra rủi ro theo kiểu “chụp nhanh” tĩnh, thay vì theo cách thức năng động và liên tục. Hơn nữa, các nguyên nhân phân loại có xu hướng làm suy yếu mối liên hệ với sự lựa chọn (tức là sự kiện rủi ro) đang tạo ra rủi ro cũng như nguyên nhân gốc rễ của nó. Ngoài ra, nhiều đơn vị phân loại không liệt kê các rủi ro mà chỉ liệt kê các yếu tố hoặc yếu tố thúc đẩy rủi ro (tức là các triệu chứng rủi ro). Điều quan trọng là phải ghi nhớ bộ ba rủi ro được thảo luận trong Phần 2.1.2 khi xác định rủi ro và mô tả rủi ro dưới dạng sự kiện có điều kiện — nếu x, thì y hoặc z có thể xảy ra.
