MỤC LỤC
1. MỤC LỤC 1
2. Phần I. Giới thiệu : 2
3. Phần II. Quản lý rủi ro 2
3.1. Rủi ro 2
3.2. Quản lý rủi ro 4
3.3. Quy trình quản lý rủi ro: 8
3.3.1. Nhận diện rủi ro: 9
3.3.2. Phân tích và phân loại rủi ro: 10
3.3.3. Kiểm soát rủi ro: 12
3.3.4. Giám sát và điều chỉnh: 13
3.4. Biện pháp quản lý rủi ro: 14
3.5. Phương pháp Riskit: 15
20 trang |
Chia sẻ: maiphuongdc | Lượt xem: 6823 | Lượt tải: 1
Bạn đang xem nội dung tài liệu Đề tài Công nghệ phần mềm - Quản lý rủi ro, để tải tài liệu về máy bạn click vào nút DOWNLOAD ở trên
hể phá huỷ toàn bộ dự án.
Quản lý rủi ro làm giảm tối thiểu khả năng rủi ro, trong khi đó tăng tối đa những cơ hội tiềm năng .
Quản lý rủi ro đã xuất hiện trong nhiều thập kỷ. Tuy nhiên chỉ vào khoảng nửa cuối thập kỷ trước nó mới thật sự trở lên quan trọng đối với cộng đồng phần mềm. Trong những năm đầu của thế kỷ trước, các dự án phần mềm chỉ được áp dụng quản lý rủi ro bằng các cách tiếp cận bộc phát, không hề theo 1 phương pháp hệ thống nào. Tuy nhiên với sự phức tạp đang được tăng lên trong việc phát triển phần mềm, nhiều ngành công nghiệp đã thấy được sự quan trọng của quản lý rủi ro. Trước khi áp dụng bất cứ 1 quá trình quản lý rủi ro nào, các thành viên trong nhóm thực hiện dự án nên nắm được rõ ràng về các hậu quả sau này của các rủi ro trong dự án của họ như:
Sự mất mát sẽ phát sinh nếu xuất hiện rủi ro: sự mất mát trong dự án phần mềm có thể kể đến như lợi nhuận, thị phần, khách hàng.
Tính nghiêm trọng của sự mất mát
Tính lâu dài của các rủi ro
Những mô hình quản lý rủi ro phần mềm phổ biến:
Đã có 1 vài cách tiếp cận quản lý rủi ro phần mềm được đề xuất trong quá khứ. Hầu hết là đánh giá rủi ro trong tất cả các giai đoạn phát triển phần mềm. Kết quả là trong những cách tiếp cận đó, các mô hình quản lý rủi ro đã được áp dụng 1 cách có kỷ luật. Đó là những cách tiếp cận sau:
Mô hình quản lý rủi ro của Boehm (win-win)
Mô hình quản lý rủi ro phần mềm của SEI
Mô hình quản lý rủi ro của Hall
Mô hình quản lý rủi ro của Karolak
Phương pháp luận rủi ro của Kontio
Những đóng góp nền tảng của Boehm: Boehm đã đề xuất 1 mô hình phát triển phần mềm là điều khiển rủi ro. Điểm mạnh trong mô hình này là đã quy công việc vào thành 1 mô hình xoắn ốc, nhiều rủi ro được loại bỏ tại những giai đoạn sớm nhất thay vì sẽ gặp phải những rào cản dự án ở những giai đoạn sau. Boehm đã mở rộng mô hình xoắn ốc của ông bằng cách sử dụng lý thuyết mô hình win-win, với mục tiêu đáp ứng các mục đích và mối quan tâm của các bên liên quan. Năm 1991, Boehm cũng đề xuất ra 1 khung quản lý rủi ro, giúp tìm ra được những nguồn rủi ro chính, phân tích và phân giải chúng.
Tiếp cận quản lý rủi ro phần mềm của SEI: SEI đã cung cấp 1 khuôn khổ quản lý rủi ro toàn diện bao gồm trong 3 nhóm: đánh giá rủi ro phần mềm, quản lý rủi ro liên tục, nhóm quản lý rủi ro.
Đánh giá rủi ro phần mềm liên quan đến nhận biết, phân tích, liên lạc và các chiến lược làm giảm nhẹ quản lý rủi ro phần mềm. Phân loại rủi ro bao gồm rủi ro trong yêu cầu, rủi ro trong thiết kế, rủi ro viết code và kiểm thử, rủi ro hợp đồng…
Quản lý rủi ro liên tục được tiếp cận trên nguyên tắc cung cấp các tiến trình, phương thức và công cụ liên tục cho quá trình quản lý rủi ro trong tất cả các giai đoạn của vòng đời phần mềm.
Nhóm quản lý rủi ro liên quan với sự phát triển của các phương pháp luận, các chương trình và các công cụ trong sự phát triển mối quan hệ giữa khách hàng và nhà cung cấp.
3 nhóm trên đều có tác dụng tương hỗ với nhau, chẳng hạn 1 nhóm được định hướng tiếp cận cho quản lý rủi ro cũng có thể hỗ trợ được cho quản lý rủi ro liên tục.
Tiếp cận mô hình của Hall:
Năm 1998 Hall đã tiếp cận quản lý rủi ro bằng xác định ra 4 nhân tố khác nhau có khả năng làm thay đổi các kết quả mong đợi của bất kỳ dự án nào. Các nhân tố đó là con người, quy trình, cơ sở hạ tầng và sự thực hiện.
Nhân tố con người liên quan tới khía cạnh nguồn nhân lực cho quản lý rủi ro. Điều này là quan trọng vì sự thành công của bất kỳ hoạt động quản lý rủi ro nào đều phụ thuộc vào sự thành công trong việc chỉ đạo thực hiện quản lý rủi ro.
Nhân tố quy trình xác định các tiến trình cần được thực hiện để quản lý rủi ro cho các bất ngờ nhỏ nhất bao hàm toàn bộ trong dự án.
Nhân tố cơ sở hạ tầng xác định các yêu cầu, các nguồn và các kết quả cần thiết để thực hiện các hoạt động quản lý rủi ro cho 1 tổ chức.
Nhân tố thực hiện liên quan tới việc tiến hành trong thực tế của các hoạt động quản lý rủi ro như đặt ra các sáng kiến cho quản lý rủi ro, phát triển kế hoạch, điều chỉnh các chương trình để phù hợp với yêu cầu, đánh giá và điều chỉnh rủi ro.
Cách tiếp cận của Karolak:
Karolak đã đưa ra cách tiếp cận giai đoạn để áp dụng cho quản lý rủi ro, tiếp cận giai đoạn là cố gắng thu nhỏ lượng rủi ro đã bao hàm, trong khi ta tối ưu hoá các chiến lược phòng chống cho các tình huống. Nó đưa đến cách tiếp cận điều khiển rủi ro và áp dụng nguyên tắc quản lý rủi ro trong những giai đoạn sớm của vòng đời phát triển phần mềm, để giảm chi phí dự án, thời gian và cải thiện mong đợi của khách hàng.
Trong cách tiếp cận này, đầu tiên ông nhận biết các hạng mục có rủi ro ở mức cao, tiếp đến kết hợp các hạng mục rủi ro đó thành nhân tố rủi ro, số liệu rủi ro và các câu hỏi được đặt ra cho người nắm giữ dự án. Những câu hỏi đó giống như danh sách kiểm tra để xác định những lớp khác nhau của nhiều rủi ro.
Tiếp cận Riskit của Kontio:
Năm 2001 Kontio đã đề xuất phương pháp Riskit, cung cấp 1 khung khái niệm hoàn thiện cho quản lý rủi ro, sử dụng mục tiêu và tiếp cận định hướng của các bên liên quan, bằng cách giữ lại mục đích của các bên liên quan và đưa nó vào quá trình quản lý rủi ro.
Áp dụng phương pháp Riskit giúp cho dự án được quản lý đúng đắn, phân tán thời gian kịp thời. Trái tim của phương pháp Riskit là biểu đồ phân tích Riskit, phân tích các nhân tố rủi ro, những sự kiện rủi ro, kết quả rủi ro, ảnh hưởng của rủi ro và những lợi ích sẽ mất khi xuất hiện rủi ro.
Sau khi thảo luận về các mô hình quản lý rủi ro quan trọng ở trên.Dưới đây ta tiếp tục thảo luận về 5 mô hình mới đề xuất gần đây.Tuy nhiên chúng chỉ đề xuất các phương pháp phân tích rủi ro mà không hoàn toàn là một khung quản lý rủi ro như chúng ta đã được tiếp cận ở trên.
Đề xuất của Foo và Murugananthan : Hai người đã đề xuất một bảng câu hỏi có phân tích các rủi ro để cung cấp cho họ đánh giá định lượng. Cách tiếp cận của họ có thể được xác định để định lượng các thành phần rủi ro,sau đó sử dụng chúng để ước lượng một giá trị chuẩn cho toàn bộ rủi ro của dự án.Mô hình của họ được gọi là mô hình đánh giá rủi ro phần mềm (SRAM=software risk assessment model).Dựa trên các yếu tố để đoán biết trước được các tình huống rủi ro.Nói cách khác mô hình đánh giá rủi ro này phụ thuộc vào tính chất của dự án
Trong mô hình này họ xét tới 9 thành phần rủi ro quan trọng : sự phức tạp của phần mềm, nhân viên dự án,xác định mục tiêu,yêu cầu của sản phẩm,phương pháp dự đoán ,phương pháp kiểm tra, quá trình phát triển được thông qua, khả năng sử dụng các phần mềm phát triển,và các công cụ
Cách tiếp cận của Daursen và Kuiper :
Năm 2003 Daursen và Kuiper đã đề xuất một giả thuyết về phương pháp đánh giá rủi ro bằng cách nhận biết những khác nhau giữa dữ liệu sơ cấp và dữ liệu thứ cấp trong một dự án.các dữ liệu sơ cấp thu được bằng cách phân tích hệ thống,dữ liệu thứ cấp thu được bằng các cuộc phỏng vấn khác nhau với các bên liên quan,rà soát hồ sơ hợp đồng,những kế hoạch dự án,xác định những yêu cầu và những hồ sơ thiết kế.Cuối cùng ,dữ liệu sơ cấp và dự liệu thứ cấp được tạo thành một nhóm, và so sánh với nhau để rút ra được những rủi ro cùng xuất hiện trong cả 2.
Phương pháp đánh giá rủi ro có sự khác biệt so với các phương pháp quản lý rủi ro sản phẩm và quản lý rủi ro chương trình khác.Ưu điểm của nó là đều kế thừa những ưu điểm của 2 phường pháp trên để giải quyết những rủi ro về mâu thuẫn quan điểm của các bên liên quan.
Cách tiếp cận của Roy :
Năm 2004 Roy đã phát triển khung quản lý ProRisk bằng cách mở rộng chuẩn AS/NZS 4350.Nó là các hạng mục quản lý rủi ro sử dụng trong thương mại miền và hoạt động miền.Nó thực hiện các hoạt động khác nhau như , nhận biết các bên liên quan , nhận biết các nhân tố rủi ro,xây dựng mô hình rủi ro,đo đạc các mô hình rủi ro,xác định xác suất của các rủi ro sự kiện
đánh giá các giá trị kết hợp của các rủi ro, phát triển các kế hoạch hành động, và theo dõi tiến độ
Quy trình quản lý rủi ro:
Nhận diện và kiểm soát tốt rủi ro chỉ bằng những kỹ năng và kinh nghiệm cá nhân không thì chưa đủ, việc kiểm soát rủi ro phải được thực hiện theo 1 quy trình chặt chẽ và phù hợp với đặc thù, mục tiêu và ngân sách của dự án.
Hình 1: Quy trình quản lý rủi ro
Nhận diện rủi ro:
Xác định được chính xác các nguồn có khả năng phát sinh rủi ro là điều không dễ dàng. Thông thường rủi ro xuất hiện từ các nguồn sau:
Ngân sách- nguồn tài trợ cho dự án
Thời gian thực hiện dự án
Thay đổi về phạm vi và yêu cầu dự án
Khó khăn về kỹ thuật
Hợp đồng giữa các bên
Môi trường, luật pháp, chính trị, văn hoá
Để nhận diện được rủi ro có nhiều kỹ thuật được áp dụng. Các kỹ thuật này giúp cho dự án khoanh vùng và xác định dấu hiệu xuất hiện rủi ro, vừa giúp tránh bỏ xót các dấu hiệu, vừa làm tăng kết quả và độ tin cậy của việc nhận diện rủi ro. Từng kỹ thuật đều có những hạn chế riêng, do đó việc kết hợp các kỹ thuật để có kết quả tốt nhất là cần thiết. Các kỹ thuật được sử dụng rộng rãi bao gồm:
Xem xét tài liệu: là cách thức xác định rủi ro cơ bản, đơn giản và thông dụng. Phương thức này thường bao gồm việc xem xét các tài liệu của dự án như các kế hoạch, giả định, cam kết với khách hàng, cơ chế thông tin giữa 2 bên, môi trường dự án, thông tin của các dự án khác trong quá khứ…, từ đó nhận diện các yếu tố có khả năng gây rủi ro cho dự án.
Động não: đây là kỹ thuật được sử dụng rộng rãi nhất để nhận diện rủi ro và hầu như bất kì ai trong đời sống đều đã từng sử dụng kỹ thuật này cho nhiều vấn đề khác nhau. Đó là sự đóng góp ý kiến từ nhiều người khác nhau, từ các chuyên gia đến các thành viên của dự án, hoặc bất cứ ai có liên quan hoặc có kinh nghiệm về các vấn đề xảy ra trong dự án. Từ những ý kiến này, các rủi ro có thể được định vị nhanh chóng.
Kỹ thuật Delphi: tương tự như kỹ thuật động não, chỉ khác là các thành viên tham gia không biết nhau, do đó kỹ thuật này thích hợp nếu các thành viên ở xa nhau. Ngày nay kỹ thuật Delphi thực hiện dễ hơn trước đây do có sự trợ giúp của email và hệ thống hỗ trợ làm việc từ xa. Do các thành viên không biết nhau nên kỹ thuật này đã hạn chế được những nhược điểm của kỹ thuật động não, đó là 1 vài cá nhân sẽ có ảnh hưởng tới suy nghĩ của cá nhân khác.
Nhóm danh nghĩa: nhóm này làm việc từ 7-10 người, mỗi thành viên sẽ ghi ý kiến riêng của mình (thường là 1 rủi ro quan trọng nhất) trên 1 mẩu giấy. Các ý kiến này sẽ được tập hợp và nhóm sẽ phân tích, đánh giá từng ý kiến. Kết quả là rủi ro quan trọng nhất sẽ được sắp xếp lên trên cùng. Kỹ thuật này không chỉ để nhận biết rủi ro mà còn để đánh giá rủi ro, được thực hiện nhanh và ít tốn kém hơn kỹ thuật Delphi.
Hỏi ý kiến chuyên gia: thường được dùng để hỏi ý kiến cá nhân của những người có kinh nghiệm từ các dự án đã hoàn thành trong quá khứ. Công cụ sử dụng thường là bảng câu hỏi có trả lời sẵn để chọn lựa hoặc để trống cho người được hỏi tự ghi ý kiến hoặc trả lời.
Sử dụng phiếu kiểm tra hoặc bảng câu hỏi: phiếu kiểm tra hoặc bảng câu hỏi thường đúc kết kinh nghiệm từ các dự án quá khứ và các dự án tương tự, trong đó liệt kê những rủi ro thường hay gặp nhất. Phiếu này giúp nhanh chóng xác định rủi ro có thể xảy đến cho dự án. Kỹ thuật này có thể tham khảo các kinh nghiệm từ bên ngoài, 1 trong những tham khảo tốt nhất theo cách này là sử dụng bảng phân loại và liệt kê các rủi ro thường gặp của viện kỹ thuật phần mềm Hoa Kỳ (SEI).
Sử dụng biểu đồ: sử dụng nhiều dạng biểu đồ khác nhau để phân tích và xác định rủi ro, chẳng hạn như biểu đồ xương cá được sử dụng để chỉ sự liên quan và ảnh hưởng của các yếu tố rủi ro khác nhau, từ đó xác định rủi ro có thể ảnh hưởng tới dự án. Biểu đồ quy trình cho thấy sự nối tiếp trong chuỗi các sự kiện, từ đó xác định các yếu tố có thể gây rủi ro cho dự án.
Hình 3: Dùng biểu đồ xương cả định vị rủi ro
Phân tích và phân loại rủi ro:
Trong thực tế, những rủi ro có thể xảy ra trong 1 dự án là khá nhiều, và việc giải quyết hết tất cả các rủi ro là không cần thiết, cũng như sẽ làm phá sản ngân sách của dự án.
Thông thường người ta áp dụng nguyên tắc 20/80 để xác định và giải quyết những rủi ro quan trọng, những nguyên nhân gốc có ảnh hưởng lớn nhất đến sự thành công của dự án, trong chừng mực cân nhắc cẩn thận ngân sách dự án cũng như 1 số yếu tố đặc biệt khác. Điều này dẫn đến việc dự án phải phân tích để chọn ra những rủi ro cần giải quyết đó. Có nhiều kỹ thuật phân tích rủi ro được sử dụng, kỹ thuật thường được sử dụng bao gồm các phân tích chính sau:
Phân tích khả năng xuất hiện của rủi ro:
Có 4 mức để đo lường khả năng xuất hiện của rủi ro, mỗi mứ được gán với 1 giá trị số để có thể ước lượng sự quan trọng của nó.
6 - Thường xuyên: khả năng xuất hiện rủi ro rất cao, xuất hiện trong hầu hết dự án.
4 - Hay xảy ra: khả năng xuất hiện rủi ro cao, xuất hiện trong nhiều dự án.
2 - Đôi khi: khả năng xuất hiện rủi ro trung bình, chỉ xuất hiện ở 1 số ít dự án
1 - Hiếm khi: khả năng xuất hiện thấp, chỉ xuất hiện trong những điều kiện nhất định.
Phân tích mức tác động của rủi ro:
Có 4 mức tác động của rủi ro, mỗi mức độ được gán với 1 giá trị số để có thể ước lượng sự tác động của nó.
8 - Trầm trọng: có khả năng làm dự án thất bại rất cao
6 - Quan trọng: gây khó khăn lớn và làm dự án không đạt được các mục tiêu
2 - Vừa phải: gây khó khăn cho dự án, ảnh hưởng việc đạt các mục tiêu của dự án.
1 - Không đáng kể: Gây khó khăn không đáng kể.
Phân tích thời điểm xuất hiện rủi ro:
Có 4 mức để ước lượng thời điểm rủi ro xuất hiện, mỗi mức được gán với 1 giá trị số để có thể ước lượng sự tác động của nó.
6 - Ngay lập tức: rủi ro xuất hiện gần như tức khắc
4 - Rất gần: rủi ro sẽ xuất hiện trong thời điểm rất gần thời điểm phân tích.
2 - Sắp xảy ra: rủi ro sẽ xuất hiện trong tương lai gần
1 - Rất lâu: rủi ro sẽ xuất hiện trong tương lai xa hoặc chưa định được.
Ước lượng và phân hạng các rủi ro:
Rủi ro được tính giá trị để ước lượng bằng công thức:
Risk Exposure = Risk Impact * Risk Probability * Time Frame
Tiếp theo rủi ro được phân hạng từ cao đến thấp dựa theo các giá trị Risk Exposure tính toán được. Tuỳ theo tổ chức và đặc thù từng dự án, trưởng dự án sẽ xác định những rủi ro nào cần đưa vào kiểm soát, với các mức ưu tiên khác nhau.
Kiểm soát rủi ro:
Kiểm soát rủi ro bắt đầu với việc chọn lựa chiến lược và phương pháp đối phó rủi ro. Có nhiều chiến lược và phương pháp đối phó rủi ro khác nhau, tuỳ theo tình huống dự án, môi trường và đặc thù của từng rủi ro. Trong thực tế, các chiến lược phổ biến bao gồm:
Hình 4: Một số chiến lược và minh hoạ các phương pháp đối phó rủi ro thường gặp
Tránh né:
Dùng “đi đường khác” để né tránh rủi ro, đường đi mới có thể không có rủi ro, có rủi ro nhẹ hơn, hoặc chi phí đối phó rủi ro thấp hơn. Chẳng hạn như:
Thay đổi phương pháp, công cụ thực hiện, thay đổi con người.
Thương lượng với khách hàng (hoặc nội bộ) để thay đổi mục tiêu.
Chuyển giao:
Giảm thiểu rủi ro bằng cách chia sẻ tác hại khi chúng xảy ra. Chẳng hạn:
Đề nghị với khách hàng chấp nhận và chia sẻ rủi ro (tăng thời gian, chi phí)
Báo cáo ban lãnh đạo để chấp nhận tác động và chi phí đối với rủi ro
Mua bảo hiểm để chia sẻ chi phí khi rủi ro xảy ra
Giảm nhẹ:
Thực thi các biện pháp để giảm thiểu khả năng xảy ra rủi ro hoặc giảm thiểu tác động và chi phí khắc phục rủi ro nếu nó xảy ra. Chẳng hạn:
Cảnh báo và triệt tiêu các yếu tố làm cho rủi ro xuất hiện.
Điều chỉnh các yếu tố có liên quan theo dây chuyền để rủi ro xảy ra sẽ ít có tác động.
Chấp nhận:
Đành chấp nhận “sống chung” với rủi ro trong trường hợp chi phí loại bỏ, phòng tránh, làm nhẹ rủi ro quá lớn (lớn hơn chi phí khắc phục tác hại), hoặc tác hại của rủi ro nếu xảy ra là nhỏ hay cực kỳ thấp. Kế hoạch đối phó có thể là:
Thu thập hoặc mua thông tin để có kế hoạch kiểm soát tốt hơn.
Lập kế hoạch khắc phục tác hại khi rủi ro xảy ra
Sử dụng cây quyết định:
Trong 1 số trường hợp phức tạp, thường rất khó xác định rủi ro nào nên đặt ưu tiên cao để kiểm soát, hoặc nên chọn chiến lược kiểm soát nào phù hợp nhất nên người ta thường sử dụng kỹ thuật hỗ trợ ra quyết định thông dụng trong quản lý là cây quyết định để tính toán giá trị đạt được hoặc thiệt hại xảy ra khi thực hiện 1 hành động nào đó.
Cây quyết định là 1 biểu đồ dạng cây có nhiều nút, mỗi nút có nhiều nhánh rẽ, mỗi nhánh rẽ sẽ trả lời câu hỏi “làm” hay “không làm”, hoặc là 1 khả năng để 1 tình huống xuất hiện với 1 xác suất nào đó. Các giá trị cuối cùng của các nhánh sẽ giúp xác định xem nên chọn phương án nào cho giá trị tốt nhất.
Ví dụ ta có cây quyết định sau:
Đây là 1 cây quyết định đơn giản để tính toán giá trị đạt được theo các phương án khác nhau, giúp chọn lựa phương án tốt nhất. Như vậy, theo cây quyết định trên, phương án Y là phương án được chọn cuối cùng do nó trả về giá trị lớn nhất.
Giám sát và điều chỉnh:
Bao gồm hoạt động giám sát để đảm bảo các chiến lược đối phó rủi ro được lên kế hoạch và thực thi chặt chẽ. Việc giám sát cũng nhằm mục đích điều chỉnh các chiến lược hoặc kế hoạch đối phó nếu chúng tỏ ra không hiệu quả, không khả thi, tốn quá nhiều ngân sách, hoặc để đáp ứng với những rủi ro mới xuất hiện, hoặc sự biến tướng của rủi ro đã được nhận diện trước đó.
Kết quả giám sát có thể được báo cáo định kỳ đến tất cả những người có liên quan, đến quản lý cấp cao, hoặc đến khách hàng nếu cần thiết.
Trong thực tế, do các yếu tố liên quan đến dự án thay đổi liên tục, chu trình quản lý rủi ro không đi theo đường thẳng mà được lặp lại và điều chỉnh liên tục giữa các chặng. Các rủi ro liên tục được điều chỉnh hoặc nhận diện mới, do đó các chiến lược và kế hoạch đối phó cũng luôn được thay đổi để đảm bảo chúng khả thi và có hiệu quả.
Biện pháp quản lý rủi ro:
Sau đây là 1 vài biện pháp nhằm quản lý được rủi ro khi triển khai các ứng dụng công nghệ thông tin tại nước ta.
a. Xử lý sớm các nguy cơ:
Để quản lý được rủi ro, cần nhận biết các nguy cơ và ước lượng được thiệt hại nếu nguy cơ xảy ra. Tiếp đến là áp dụng các biện pháp để giám sát, ngăn ngừa, hoặc tránh né nguy cơ đó. Nếu phòng mà không tránh, rủi ro vẫn xảy ra, thì phải xử lý hậu quả theo cách hạn chế thiệt hại ở mức thấp nhất và khôi phục lại các giá trị bị mất mát nhanh chóng và toàn vẹn nhất có thể. Việc xử lý này thường được gọi là các biện pháp khắc phục rủi ro, như là một vế ứng đối với “phòng ngừa rủi ro”. Ai cũng nói là “phòng hơn chống”, trên thực tế, “phòng” và “chống” phải bổ sung và hỗ trợ lẫn nhau mới đảm bảo thành công cho một dự án QL rủi ro, theo nghĩa sau đây: phòng tốt đi đến chống sớm, cái giá phải trả sẽ nhẹ nhàng hơn.
Tình huống sau đây khá điển hình: một dự án ứng dụng CNTT khi gặp phải khó khăn không kết thúc được rất thường bị “khê đọng” - “bỏ thì thương, vương thì tội” trong một thời gian khá dài, dẫn đến lãng phí lớn về tài sản và nhân lực. Nhiều khi hệ thống dù không khai thác được như ý, vẫn phải bảo trì, không có phương án giải quyết dứt điểm dù thời gian đã qua cả năm bảy năm, không thể rút được bài học và kinh nghiệm một cách đúng đắn cho việc triển khai các dự án mới... Không hiếm gặp hiện tượng chuyển từ thái cực này sang thái cực kia (từ tự phát triển sản phẩm sang giao phó hoàn toàn cho người khác hoặc mua sản phẩm bán sẵn cả gói mà không chú ý đúng mức đến nhu cầu và khả năng ứng dụng, từ đặt mục tiêu quá lớn cho tin học hóa sang xóa bỏ hoặc gác lại việc tin học hóa, từ tập trung xây dựng một phòng CNTT mạnh sang giải tán đội ngũ chuyên viên tin học...). Như thế là rủi ro này kéo theo rủi ro khác, và cái sau còn có nguy cơ lớn hơn cái trước rất nhiều.
Đối với các dự án trên, nếu có chiến lược và biện pháp quản lý rủi ro tốt thì có thể khắc phục từ sớm các nguy cơ, hậu quả gây ra và phí tổn khắc phục cũng nhỏ hơn nhiều.
b. Chú ý đến khả năng tiếp nhận công nghệ:
Các đề tài hoặc nhiệm vụ ứng dụng đến nay vẫn có xu hướng tập trung cho các đầu tư về trang bị công nghệ, chạy theo các công nghệ tiên tiến, mà không đánh giá một cách xác đáng về khả năng QL và tiếp nhận công nghệ đó trên thực tế. Phần lớn các đề tài xây dựng hệ thống thông tin và cơ sở dữ liệu chỉ đầu tư cho việc phát triển hệ thống, còn sau khi nghiệm thu thì việc cập nhật thông tin và đưa hệ thống vào sử dụng là chuyện của người khác, thậm chí của đơn vị khác. Việc cắt rời các giai đoạn của vòng đời một hệ thống như vậy sẽ không cho phép đầu tư sớm các biện pháp phòng ngừa rủi ro, đặc biệt là không quan tâm đến các khía cạnh triển khai chứa đựng rất nhiều nguy cơ.
c. Quản lý các thay đổi:
Tình trạng sau đây rất phố biến: hệ thống vừa nghiệm thu, đã có nhu cầu nâng cấp hoặc thay đổi. Giải pháp thường được áp dụng là: chia nhỏ, rút ngắn thời gian dự án. Đây là một chiến thuật có thể hợp lý, tuy nhiên chỉ là một khía cạnh để đối phó với tình hình. Việc thay đổi các yêu cầu đối với hệ thống CNTT, môi trường ứng dụng của chúng và các công cụ thực hiện cần được nhìn nhận và xử lý ở tầm chiến lược. Do đó, cần phân biệt những thành phần bền vững, có giá trị khai thác lâu dài, với những công cụ và phương tiện thường biến đổi nhanh. Thí dụ việc ồ ạt “web hóa”, “portal hóa” các hệ thống thông tin hiện nay nên được hiểu chỉ là phần nổi, việc xây dựng cơ sở dữ liệu, cơ sở nội dung mới quyết định hiệu quả các hệ thống đó. Tóm lại, QL thay đổi là vấn đề chiến lược, chứ không phải chiến thuật. Nó cần dựa trên quy hoạch ứng dụng tổng thể, dài hơi. Không thể bỏ qua hoặc xử lý thay đổi kiểu “du kích” và có đến đâu làm đến đấy. d. Hiệu quả của các quy định thực tế hàng ngày:
Các biện pháp thực tế có thể giảm thiểu đáng kể các nguy cơ cho các hệ thống thông tin, cũng như khắc phục sớm chúng, có liên quan rất nhiều đến vấn đề tổ chức và thay đổi nề nếp làm việc. Hiện nay, gần như tất cả nhân viên đều đã và phải làm việc với máy tính. Vì thế, các kỹ năng làm việc cơ bản trong môi trường công nghệ này phải được chuẩn hóa và trở thành chuẩn bắt buộc với mọi người làm việc. Giống như đi xe gắn máy phải học luật giao thông, có bằng lái và luôn tuân thủ luật lệ. Tiếp đến, các quy chế làm việc với máy tính và các tài nguyên trên máy phải được xây dựng hợp lý và chặt chẽ. “Nội quy” làm việc thời số hóa này phải được rèn luyện, kiểm tra và áp dụng thường xuyên đến thành tự giác cho mọi người. Sau đó, việc giao ban hệ thống và ghi chép biên bản cần được áp dụng đúng quy định. Các biện pháp xử lý cũng phải được lưu giữ và giám sát. Các quy định này trên thực tế nhiều nơi đã đặt ra, vấn đề là chúng phải được áp dụng một cách thực chất, không hình thức, và phải là công cụ thực sự cho việc giám sát và phát hiện các nguy cơ.
Phương pháp Riskit:
a. Chức năng và phạm vi:
a.1. Chức năng:
Tiến trình Riskit có 2 chức năng:
Thứ nhất,Riskit cung cấp cho người quản lý dự án và những bên liên quan những thông tin đúng đắn,kịp thời về những rủi ro và những khả năng của dự án.Việc biết được những rủi ro có trong dự án là rất cần thiết để đưa ra một quyết định cho dự án và những chức năng của nó, đặc biệt là trong việc đánh giá những lợi nhuận buôn bán tiềm lực , chi phí, và những rủi ro liên quan với dự án. Về bản chất, quản lý rủi ro sẽ giúp cho tổ chức loại bỏ được những rủi ro ảnh hưởng để có thể thu được lợi nhuận lớn nhất.
Thứ hai,tiến trình Riskit cung cấp một cách hệ thống về cách nhận biết, phân tích và điều khiển những rủi ro đe dọa tới dự án.Có 2 cách để thực hiện hoạt động này:
+ on one hand: chức năng là nhận biết,phân tích và điều khiển những rủi ro lộ ra như giới hạn hoặc giảm tần suất và hậu quả tiềm năng của rủi ro.
+ on other hand: quản lý rủi ro cũng cố gắng để xác định và tận dụng cơ hội có thể sẽ được trình bày và chỉ đạo dự án để nó mất tính rủi ro có khả năng mang lại các lợi ích kinh doanh.
a.2. Phạm vi:
Phạm vi của quá trình Riskit có thể được áp dụng trong tên miền, thời gian và tổ chức.
- Phương thức Riskit được dùng hỗ trợ những dự án phần mềm ứng dụng miền như phát triển hệ thống nhúng, hệ thống giao dịch, ứng dụng liên lạc, thương mại điện tự và chương trình khác nữa.
- Phạm vi thời gian của phương thức Riskit được bắt đầu từ giai đoạn khởi đầu của một dự án phần mềm cho tới khi kết thúc dự án. Đây không phải là một phương thức được thiết kế đặc biệt để dùng bảo trì hoặc dùng để giảm các giai đoạn sản xuất phần mềm, nhưng lại có nhiều khả năng hữu dụng như có thể được dùng để xác định các mục tiêu tiến hành, các thành phần chủ yếu và có thể áp dụng được nhiều lần
- Trong phạm vi tổ chức phương pháp Riskit nhắm tới những người quản lý dự án , chương trình và các nhóm quản lý. Nhân viên dự tham gia trong tiến trình cũng được cung cấp những hiểu biết và những thông tin trong các hoạt động quản lý rủi ro đã được đề xuất.
b. Tiến trình Riskit:
Bước đầu tiên trong chương trình Riskit là xác định người quản lý rủi ro.Chức năng của người quản lý rủi ro là tìm ra những người có trách nhiệm sau đo chia công việc cho người này quản lý rủi ro thành viên và cách thực hiện nó trong dự án. Người quản lý rủi ro xác định mục tiêu và phạm vi cho các người quản lý rủi ro thành viên đồng thời qui trách nhiệm và phân quyền cho họ.xác định những chức năng, thủ tục và các báo cáo được sử dụng trong việc quản lý rủi ro và cách làm thế nào để thường xuyên hoàn thành công việc.
Bước tiếp theo trong chương trình Riskit là xem lại các mục tiêu. Chức năng của bước này là để hiểu rõ hơn, và nếu như cần thiết thì có thể
Các file đính kèm theo tài liệu này:
- cong_nghe_phan_mem_quan_ly_rui_ro_388.doc