INFOCHIEF ACADEMY · IT PROJECT MANAGEMENT KNOWLEDGE SERIES
Xây dựng Risk Register: Nhận diện, đánh giá và lập phương án ứng phó rủi ro.
Risk Register phải dẫn tới hành động trước khi bất định tạo thiệt hại. Mô tả nguyên nhân, sự kiện, tác động cùng người sở hữu, phương án và dấu hiệu kích hoạt giúp đội chủ động xử lý rủi ro.
Biên soạn: Infochief Academy · Chuyên đề: Quản lý dự án IT
Một sổ rủi ro có thể được cập nhật đều mà dự án vẫn bị bất ngờ trước điều đã ghi trong đó. Trong một tình huống giả định, đội chuyển đổi hệ thống nhận diện khả năng dữ liệu nguồn thiếu chất lượng. Mục rủi ro được đánh giá cao và giao cho một đầu mối, nhưng không có bước kiểm tra trước khi chạy thử. Khi dữ liệu bị trả lại, dự án mới tìm người đối soát và xin thêm thời gian. Việc ghi nhận đã diễn ra; việc ứng phó chưa diễn ra.
Risk Register là nơi giữ thông tin về rủi ro cùng đánh giá, trách nhiệm và phương án xử lý. Nó phải giúp dự án quyết định cần làm gì trước khi bất định trở thành thiệt hại. Nếu chỉ có tên, màu và người phụ trách, sổ dễ trở thành một danh mục lo ngại không nối với kế hoạch thực hiện.
Viết rủi ro theo nguyên nhân, sự kiện và tác động
Rủi ro cần mô tả điều chưa chắc xảy ra và mục tiêu có thể bị ảnh hưởng. Một câu “dữ liệu kém” chưa cho biết tình trạng đang có hay khả năng trong tương lai. Có thể viết cụ thể hơn: do chưa có bằng chứng đối soát dữ liệu nguồn, dữ liệu chuyển đổi có thể không được chấp nhận, khiến kiểm thử hoặc mốc triển khai bị ảnh hưởng. Cấu trúc này giúp phân biệt nơi cần phòng ngừa và hậu quả cần chuẩn bị.
Không phải mọi điều chưa biết đều phải thành một mục rủi ro riêng. Cần ưu tiên bất định có ý nghĩa đối với phạm vi, lịch, chi phí, chất lượng hoặc kết quả sử dụng. Một giả định quan trọng nên được kiểm tra xem nếu sai sẽ tạo hệ quả nào. Những vấn đề đã xảy ra cần được đưa vào cơ chế xử lý vấn đề hiện hữu, đồng thời xem chúng tạo ra rủi ro mới gì.
Nguồn nhận diện nên đi qua gói công việc, phụ thuộc và điểm bàn giao. Các chuyên gia kỹ thuật có thể thấy bất định giải pháp; nghiệp vụ thấy mức sẵn sàng quy trình; vận hành thấy khả năng hỗ trợ và phục hồi. Một cuộc họp chỉ có người quản lý dự án khó bao quát đầy đủ. Cần mời đúng bên có thông tin và ghi nguyên nhân cụ thể họ đang quan sát.
Năng lực lập kế hoạch trong chương trình Quản Lý Dự Án IT giúp gắn rủi ro với công việc cần kiểm soát. Sau khi viết rõ, đội mới đánh giá được mức quan trọng thay vì chấm điểm những câu có phạm vi khác nhau.
Đánh giá để chọn hành động, không chỉ để xếp màu
Khả năng xảy ra và mức tác động là hai góc nhìn thường dùng để sàng lọc. Doanh nghiệp cần định nghĩa thang đánh giá trước khi sử dụng. Tác động có thể được xét theo ngày chậm, chi phí, khả năng vận hành hoặc những điều kiện không được phép vi phạm. Nếu các bên dùng các nghĩa khác nhau cho chữ cao, kết quả tổng hợp sẽ thiếu nhất quán.
Ma trận định tính giúp tổ chức thảo luận nhưng không biến thứ bậc thành xác suất chính xác. Điểm cao hơn chưa chắc đại diện cho mức thiệt hại lớn hơn theo một tỷ lệ tương ứng. Một rủi ro ít khả năng nhưng hậu quả nghiêm trọng có thể cần xử lý riêng. Người quản lý phải giữ lời giải thích và căn cứ, không để con số tổng hợp thay toàn bộ nhận định.
Thời điểm có thể xảy ra và thời gian còn để ứng phó cũng quan trọng. Rủi ro có thể tác động tháng sau nhưng cần chuẩn bị ngay vì mua sắm mất nhiều thời gian. Rủi ro khác có thể đang gần hết cửa sổ ảnh hưởng. Việc ưu tiên nên nhìn cả tính khẩn cấp và khả năng can thiệp, không chỉ nhìn một điểm số.
Bảng dưới đây là bộ câu hỏi đánh giá đề xuất, chưa phải một thang điểm hoặc ngưỡng áp dụng cho mọi tổ chức.
| Góc đánh giá | Câu hỏi cần làm rõ | Kết quả phục vụ quyết định |
|---|---|---|
| Khả năng | Bằng chứng nào cho thấy sự kiện có thể xảy ra? | Cơ sở của mức đánh giá |
| Tác động | Mục tiêu nào bị ảnh hưởng và theo cơ chế nào? | Hậu quả cần bảo vệ |
| Thời điểm | Khi nào rủi ro có thể tác động? | Hạn phải chuẩn bị |
| Khả năng ứng phó | Có thể thay đổi nguyên nhân hoặc hậu quả ra sao? | Lựa chọn hành động |
| Quyền xử lý | Ai được phép chấp nhận hoặc chi để ứng phó? | Nơi cần quyết định |
Trong tình huống mở bài, việc chưa kiểm tra dữ liệu là cơ sở để đặt một hành động xác minh. Không nhất thiết phải chờ biết chính xác xác suất mới bắt đầu. Một thử nghiệm giới hạn có thể vừa làm giảm bất định vừa giúp điều chỉnh phương án. Đánh giá cần tạo ra bước tiếp theo phù hợp với bằng chứng hiện có.
Chọn ứng phó ở nơi có thể tác động
Với nguy cơ bất lợi, đội có thể xem xét tránh, giảm, chuyển giao hoặc chấp nhận theo điều kiện thực tế. Tránh có thể là đổi cách triển khai để loại bỏ một nguồn rủi ro. Giảm có thể là kiểm tra sớm hoặc bổ sung kiểm soát. Chuyển giao một phần trách nhiệm qua hợp đồng không làm mọi hậu quả biến mất; doanh nghiệp vẫn cần đánh giá sự liên tục và khả năng thực hiện của bên nhận.
Chấp nhận cũng cần là một quyết định rõ. Có thể chấp nhận với phương án dự phòng và nguồn lực phù hợp, hoặc chấp nhận theo dõi khi chưa có biện pháp đáng thực hiện. Không nên để một mục không có hành động tự động được hiểu là đã chấp nhận. Người có thẩm quyền cần biết hậu quả còn lại và lý do chọn cách xử lý.
Rủi ro cũng có thể tạo cơ hội, chẳng hạn khả năng sử dụng một giải pháp thử nghiệm để giảm một phần công việc. Cơ hội cần được đánh giá cùng điều kiện và chi phí khai thác, không được đưa vào kế hoạch như lợi ích chắc chắn. Nếu có mục tiêu thúc đẩy kết quả thuận lợi, hãy xác định người và hành động tương ứng. Sổ rủi ro không nhất thiết chỉ chứa những điều có thể gây thiệt hại.
Chuyên môn quản lý an toàn thông tin cần tham gia những rủi ro liên quan dữ liệu và quyền truy cập. Người quản lý dự án không nên tự chấp nhận sự đánh đổi thuộc trách nhiệm an toàn thông tin hoặc nghĩa vụ kiểm soát của doanh nghiệp. Phương án ứng phó phải được người có khả năng tác động xác nhận.
Tách người sở hữu rủi ro khỏi người làm từng hành động
Người sở hữu rủi ro chịu trách nhiệm theo dõi, đánh giá và thúc đẩy xử lý trong phạm vi được giao. Một hành động cụ thể có thể do người khác thực hiện. Với dữ liệu, chủ sở hữu có thể là người quản lý phần chuyển đổi, còn hành động đối soát do chuyên viên nghiệp vụ làm. Nếu chỉ giao một tên cho cả mục mà không phân công hành động, trách nhiệm dễ dừng ở báo cáo.
Mỗi hành động cần có kết quả, hạn và bằng chứng hoàn tất. “Phối hợp với nghiệp vụ” chưa đủ để giảm rủi ro; “kiểm tra tập dữ liệu mẫu theo quy tắc đã thống nhất và ghi các ngoại lệ” cụ thể hơn. Hành động ứng phó quan trọng nên xuất hiện trong lịch và ngân sách, không chỉ trong sổ. Nếu thiếu năng lực thực hiện, phải đưa việc này vào quyết định nguồn lực.
Cần phân biệt đánh giá trước ứng phó với mức còn lại sau khi biện pháp đã được thực hiện hoặc với dự báo mức còn lại. Một biện pháp mới có kế hoạch chưa chứng minh rủi ro đã giảm. Khi dùng các cột đánh giá, tên phải rõ để người đọc không hiểu nhầm mức kỳ vọng là trạng thái thực tế. Bằng chứng hiệu lực cần được xem sau hành động.
Đội Quản Lý Dịch Vụ IT – ITSM có thể hỗ trợ kiểm tra phương án phục hồi và tính sẵn sàng hỗ trợ. Những phương án chỉ tồn tại trên giấy cần được thử ở mức phù hợp trước khi trở thành cơ sở để cho phép triển khai.
Đặt dấu hiệu kích hoạt và chuẩn bị cho tình huống xảy ra
Dấu hiệu cảnh báo sớm giúp nhận biết rủi ro đang tăng, còn điều kiện kích hoạt xác định khi nào phải chuyển sang phương án đã chuẩn bị. Với dữ liệu, cảnh báo có thể là nhiều ngoại lệ chưa được giải quyết trước một điểm kiểm tra. Điều kiện kích hoạt có thể là dữ liệu chưa được chấp nhận vào hạn cần để bảo vệ lịch. Doanh nghiệp phải định nghĩa theo tình huống cụ thể, không sử dụng một ngưỡng chung thiếu căn cứ.
Phương án dự phòng cần có người quyết định và người thực hiện. Nếu chọn triển khai giới hạn hoặc dời mốc, phải biết ảnh hưởng nghiệp vụ và điều kiện quay lại. Nguồn lực dự phòng cũng cần được chuẩn bị theo quyền. Một lựa chọn yêu cầu chuyên gia không thể bố trí trong thời gian còn lại chưa phải phương án khả thi.
Khi sự kiện xảy ra và tạo vấn đề cần giải quyết, cần mở mục Issue Log liên kết với rủi ro ban đầu. Đánh giá lại các hậu quả chưa chắc xảy ra để không bỏ mất phần bất định còn lại. Việc liên kết giúp giữ lịch sử nhưng tránh ghi hai lần cùng một hành động ở hai nơi rồi báo cáo trùng. Sổ rủi ro có thể tiếp tục theo dõi phần còn mở với trạng thái phù hợp.
Các mục vượt khả năng xử lý phải được trình lên bằng quyết định cần chốt. Năng lực điều hành của Giám Đốc Dự Án IT giúp chuyển rủi ro thành lựa chọn về nguồn lực, lịch hoặc phạm vi. Đề nghị cần có thời hạn và hệ quả nếu chưa quyết định.
Rà soát khi thông tin thay đổi, không chỉ theo lịch họp
Sổ cần được xem lại khi có thay đổi phạm vi, giải pháp, nhân sự hoặc điều kiện bên ngoài. Nhịp định kỳ giúp giữ kỷ luật, nhưng các phát hiện lớn không nên chờ tới cuộc họp kế tiếp. Mỗi lần rà cần hỏi nguyên nhân còn tồn tại không, hành động có hiệu lực không và có rủi ro mới do biện pháp ứng phó tạo ra không.
Một mục có thể đóng khi không còn khả năng ảnh hưởng mục tiêu theo điều kiện đã xác nhận, hoặc được chuyển trách nhiệm hợp lệ. Không nên đóng chỉ vì thời gian dài không có sự kiện. Những rủi ro chưa xảy ra có thể vẫn đang tăng khi mốc tiếp cận. Lý do đóng cùng người xác nhận cần được giữ để tránh hiểu rằng rủi ro đã được giải quyết bằng một thao tác trạng thái.
Với tình huống chuyển dữ liệu, hãy chọn một tập mẫu, kiểm tra điều kiện chấp nhận và đặt hành động vào lịch trước lần chạy thử. Sau đó cập nhật rủi ro bằng kết quả thực tế. Một Risk Register có giá trị giúp đội chủ động thay đổi điều kiện gây thất bại, đồng thời chuẩn bị lựa chọn khi phòng ngừa không đủ. Số dòng được cập nhật không quan trọng bằng những quyết định và hành động đã diễn ra từ chúng.