title: "Dự báo rủi ro: Trở thành người "báo động sớm" cho các rủi ro mà khách chưa nhìn thấy"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 3 — Tư duy Chiến lược & Tầm nhìn"
skill_number: 32
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "11 phút đọc"
tags: ["du-bao-rui-ro", "risk-register", "quan-tri-rui-ro", "single-point-of-failure", "tu-duy-chien-luoc", "ea-skills"]

Dự báo rủi ro: Trở thành người "báo động sớm" cho các rủi ro mà khách chưa nhìn thấy

Khách hàng thuê bạn để giao đúng những gì họ yêu cầu trong tài liệu — nhưng giá trị thật của một BA/EA kỳ cựu nằm ở những thứ không ai yêu cầu bạn tìm ra. Bạn có sẵn sàng gõ cửa phòng họp của khách để báo một rủi ro mà chưa ai hỏi, chưa có sự cố nào xảy ra, và việc nói ra có thể khiến chính bạn bị coi là "làm phức tạp vấn đề"? Đây chính là ranh giới giữa một người thực thi yêu cầu và một người bảo vệ lợi ích dài hạn của khách hàng.

🎯 Kỹ thuật cốt lõi: Risk Register (Đăng ký rủi ro)

Risk register là một công cụ quản trị rủi ro đơn giản nhưng cực kỳ mạnh nếu dùng đúng cách: một danh sách sống (living document) liệt kê từng rủi ro tiềm ẩn, đánh giá theo hai trục — khả năng xảy ra (likelihood) và mức độ tác động (impact) — rồi gắn với một chủ sở hữu (owner) và hành động giảm thiểu cụ thể. Khác với báo cáo sự cố (viết SAU khi việc đã xảy ra), risk register được viết TRƯỚC, khi rủi ro còn là một khả năng.

Cấu trúc tối thiểu của một dòng trong risk register:

Cách dùng risk register tổng quát cho mọi tình huống, không chỉ riêng dự án CNTT:

1. Quét chủ động, không đợi ai hỏi. Ở bất kỳ giai đoạn nào của dự án — khảo sát, thiết kế, triển khai — luôn tự hỏi: "Có điểm nào trong hệ thống/quy trình này mà nếu một mắt xích hỏng, cả chuỗi sụp đổ không?" Đây là cách tìm ra các rủi ro dạng single point of failure (điểm lỗi duy nhất — một thành phần mà nếu hỏng sẽ làm cả hệ thống ngưng trệ, không có phương án dự phòng).
2. Viết ra ngay khi phát hiện, đừng giữ trong đầu. Một rủi ro chưa được viết vào risk register coi như chưa tồn tại về mặt quản trị — nó dễ bị quên, và nếu xảy ra sự cố, không ai chứng minh được đã có cảnh báo trước.
3. Đánh giá khách quan, không thổi phồng cũng không hạ thấp. Dùng dữ liệu thực tế (thời gian uptime của nhà cung cấp, lịch sử sự cố, hợp đồng SLA...) thay vì cảm tính để xếp hạng khả năng và tác động.
4. Gắn chủ sở hữu và hành động cụ thể — không để rủi ro "mồ côi". Một rủi ro không có ai chịu trách nhiệm theo dõi thì risk register chỉ là một file Excel trang trí.
5. Đưa lên bàn khách hàng bằng ngôn ngữ nghiệp vụ, không chỉ ngôn ngữ kỹ thuật. Khách hàng không cần biết chi tiết kỹ thuật, họ cần biết: nếu điều này xảy ra, việc kinh doanh của họ bị ảnh hưởng thế nào, và chi phí phòng ngừa so với chi phí nếu để xảy ra là bao nhiêu.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ nhiều dự án thực tế, không phải case cụ thể của một công ty nào.

Anh T., Enterprise Architect (EA) được thuê tư vấn kiến trúc cho một doanh nghiệp bán lẻ đang chuẩn hoá lại toàn bộ hệ thống thanh toán và đối soát (reconciliation) trên nền tảng thương mại điện tử của họ. Phạm vi hợp đồng rất rõ ràng: rà soát kiến trúc hiện tại, đề xuất tối ưu luồng dữ liệu giữa hệ thống bán hàng, kho vận và kế toán. Không ai yêu cầu anh T. đánh giá các nhà cung cấp dịch vụ bên thứ ba.

Trong quá trình vẽ sơ đồ luồng dữ liệu (data flow diagram) để phục vụ đúng phạm vi được giao, anh T. nhận ra một điều nằm ngoài yêu cầu: toàn bộ luồng xử lý thanh toán — từ cổng thanh toán (payment gateway), xác thực giao dịch, đến webhook báo kết quả về hệ thống nội bộ — đều đi qua MỘT nhà cung cấp payment gateway duy nhất. Không có phương án dự phòng (fallback), không có nhà cung cấp thứ hai, và hợp đồng với nhà cung cấp này không có điều khoản cam kết uptime rõ ràng (SLA — thoả thuận mức dịch vụ). Khi anh T. hỏi dò đội IT nội bộ khách hàng, câu trả lời là: "Từ trước đến giờ vẫn chạy ổn, chưa nghĩ đến chuyện đổi hay thêm nhà cung cấp khác."

Thách thức (Task)

Cái khó ở đây không nằm ở việc phát hiện ra rủi ro — với con mắt kiến trúc, việc nhận ra một single point of failure không quá khó. Cái khó là quyết định có nên nói ra hay không, và nói như thế nào.

Ba áp lực khiến việc này không đơn giản:

Thứ nhất, đây không nằm trong phạm vi hợp đồng (scope). Nếu anh T. dành thời gian phân tích và trình bày một rủi ro ngoài phạm vi, điều đó có thể bị hiểu là "lấn sân", làm phình to công việc (scope creep theo chiều ngược — tự thêm việc chưa được yêu cầu và chưa được trả phí), hoặc tệ hơn là bị xem như đang cố bán thêm dịch vụ tư vấn không cần thiết.

Thứ hai, đây là rủi ro của một hệ thống đang chạy ổn định nhiều năm. Nói rủi ro cho một hệ thống MỚI xây thì dễ được lắng nghe; nhưng nói "hệ thống đang chạy tốt của các anh chị có một lỗ hổng nghiêm trọng" dễ khiến người nghe phòng thủ, đặc biệt nếu đội IT nội bộ khách hàng chính là người đã chọn nhà cung cấp đó từ đầu.

Thứ ba, và quan trọng nhất: đây là rủi ro xác suất thấp nhưng tác động cực lớn. Nhà cung cấp thanh toán có thể chạy ổn định 3 năm liền, và cũng có thể sập đúng vào ngày cao điểm bán hàng (Black Friday, sale cuối năm...). Loại rủi ro "ít khi xảy ra nhưng khi xảy ra thì thảm hoạ" luôn khó thuyết phục hơn loại rủi ro xảy ra thường xuyên và dễ thấy — vì con người có xu hướng đánh giá thấp xác suất hiếm khi chưa có tiền lệ xấu.

Nếu anh T. im lặng vì "không nằm trong phạm vi hợp đồng", và một ngày nhà cung cấp thanh toán đó gặp sự cố (ngừng hoạt động, bị tấn công, phá sản, thay đổi chính sách đột ngột), toàn bộ doanh thu online của khách hàng sẽ đóng băng — và không ai có thể nói "không ai biết trước được", vì thực ra ĐÃ có người biết.

Hành động (Action)

Bước 1 — Không vội cảnh báo bằng miệng, viết vào risk register trước. Ngay khi phát hiện, anh T. không chạy ngay đến gặp khách hàng nói "tôi phát hiện vấn đề nghiêm trọng". Anh dành nửa ngày để viết rủi ro này thành một dòng risk register hoàn chỉnh: mô tả rõ ràng ("100% giao dịch thanh toán phụ thuộc vào một nhà cung cấp duy nhất, không có phương án dự phòng, hợp đồng không có SLA uptime rõ ràng"), đánh giá khả năng xảy ra (thấp — nhà cung cấp đã hoạt động ổn định) và tác động (rất cao — toàn bộ doanh thu online ngừng trệ nếu xảy ra sự cố).

Bước 2 — Lượng hoá tác động bằng ngôn ngữ kinh doanh, không chỉ ngôn ngữ kỹ thuật. Anh T. không viết "nguy cơ downtime của payment gateway" một cách trừu tượng. Anh ước tính: nếu nhà cung cấp ngừng hoạt động 4 giờ vào một ngày bán hàng bình thường, dựa trên doanh thu trung bình theo giờ khách hàng đã chia sẻ trong các buổi khảo sát trước đó, con số thiệt hại doanh thu trực tiếp là bao nhiêu — chưa kể chi phí uy tín thương hiệu. Việc gắn con số cụ thể (dù là ước tính minh hoạ, có ghi rõ giả định) biến một rủi ro kỹ thuật mơ hồ thành một câu chuyện kinh doanh mà ban lãnh đạo hiểu ngay.

Bước 3 — Kiểm tra chéo trước khi nói ra, tránh báo động sai. Anh T. không dựa vào phỏng đoán. Anh xin xem lại hợp đồng với nhà cung cấp thanh toán, xác nhận đúng là không có điều khoản SLA ràng buộc mức uptime, và tra cứu lịch sử sự cố công khai (nếu có) của nhà cung cấp này trong ngành để có thêm căn cứ khách quan, tránh tình trạng "cảnh báo cho có" thiếu bằng chứng.

Bước 4 — Chủ động xin một khung thời gian riêng để trình bày, tách bạch với báo cáo phạm vi chính. Thay vì chèn rủi ro này vào báo cáo tối ưu kiến trúc (dễ bị chìm giữa các nội dung khác), anh T. chủ động nhắn cho đầu mối phía khách hàng: "Trong quá trình rà soát kiến trúc theo phạm vi đã thống nhất, em phát hiện một điểm nằm ngoài phạm vi nhưng em nghĩ quan trọng đủ để báo riêng — xin 15 phút để trình bày, không tính thêm phí tư vấn cho phần này." Việc nói rõ "không tính thêm phí" ngay từ đầu loại bỏ ngay nghi ngờ về động cơ trục lợi.

Bước 5 — Trình bày theo cấu trúc risk register: rủi ro — bằng chứng — tác động — phương án, không phán xét quyết định cũ. Trong buổi trình bày, anh T. cố tình không nói "đội IT của các anh chị đã chọn sai nhà cung cấp". Anh trình bày trung lập: "Đây là một thiết kế phổ biến khi hệ thống mới triển khai và một nhà cung cấp là đủ. Giờ quy mô giao dịch đã lớn hơn, rủi ro tập trung vào một điểm duy nhất đáng được xem xét lại." Anh đưa ra risk register với điểm rủi ro cụ thể, và ba phương án giảm thiểu ở các mức chi phí khác nhau: (1) đàm phán lại hợp đồng để có SLA uptime rõ ràng và cơ chế bồi thường, (2) tích hợp thêm một nhà cung cấp thanh toán dự phòng cho một phần giao dịch (kiến trúc multi-provider), (3) xây dựng cơ chế chuyển đổi thủ công khẩn cấp (manual failover) cho tình huống khẩn cấp trong lúc chưa đủ ngân sách làm phương án 2.

Bước 6 — Để khách hàng tự quyết định mức độ ưu tiên, không ép phải hành động ngay. Anh T. không yêu cầu khách hàng phải xử lý ngay lập tức — anh đưa rủi ro này vào risk register chính thức của dự án, đề xuất người sở hữu (owner) phía khách hàng là trưởng phòng IT, và gợi ý mốc rà soát lại sau mỗi quý. Vai trò của anh là người báo động sớm và cung cấp phương án, quyền quyết định đầu tư bao nhiêu ngân sách để giảm rủi ro thuộc về khách hàng.

Kết quả (Result)

Ban lãnh đạo khách hàng, sau khi nghe con số ước tính thiệt hại doanh thu nếu sự cố xảy ra vào ngày cao điểm, quyết định không đầu tư ngay vào phương án multi-provider (chi phí và thời gian triển khai lớn), nhưng phê duyệt ngay hai việc rẻ và nhanh hơn: đàm phán lại hợp đồng với nhà cung cấp hiện tại để bổ sung điều khoản SLA và cơ chế cảnh báo sớm khi có sự cố, và giao đội IT xây dựng quy trình chuyển đổi thủ công khẩn cấp trong vòng 3 tuần.

Sáu tháng sau, nhà cung cấp thanh toán gặp sự cố gián đoạn khoảng 90 phút vào một buổi tối bình thường (không phải ngày cao điểm). Nhờ đã có quy trình cảnh báo sớm từ điều khoản SLA mới, đội IT khách hàng phát hiện và kích hoạt quy trình dự phòng thủ công trong vòng 20 phút thay vì để khách hàng cuối tự phát hiện lỗi thanh toán, giảm đáng kể lượng đơn hàng bị huỷ giữa chừng.

Điều chưa hoàn hảo: phương án multi-provider (giải pháp triệt để nhất) vẫn chưa được triển khai vì lý do ngân sách, nghĩa là rủi ro gốc — sự phụ thuộc vào một nhà cung cấp duy nhất — về bản chất vẫn còn tồn tại, chỉ là mức độ tác động khi xảy ra sự cố đã được giảm bớt phần nào. Risk register của dự án vẫn giữ dòng rủi ro này ở trạng thái "đang theo dõi" thay vì "đã đóng", đúng với thực tế chưa xử lý triệt để.

📋 Áp dụng ngay

• Trong bất kỳ dự án nào, dành thời gian tự hỏi "có mắt xích nào ở đây mà nếu hỏng sẽ làm sập cả chuỗi, và có phương án dự phòng chưa" — dù câu hỏi này không nằm trong phạm vi được giao.
• Viết mọi rủi ro phát hiện được vào một risk register sống, có đủ bốn trường: khả năng, tác động, người sở hữu, hành động giảm thiểu — đừng chỉ giữ trong đầu hoặc nhắc miệng một lần rồi quên.
• Khi báo cáo rủi ro ngoài phạm vi hợp đồng, minh bạch ngay từ đầu về việc có tính phí hay không, để tránh bị hiểu lầm về động cơ.
• Lượng hoá tác động bằng ngôn ngữ kinh doanh (doanh thu, thời gian ngừng trệ, chi phí) thay vì thuần ngôn ngữ kỹ thuật khi trình bày với khách hàng không chuyên IT.
• Luôn kèm tối thiểu 2-3 phương án giảm thiểu ở các mức chi phí khác nhau, để khách hàng có quyền chọn mức độ đầu tư phù hợp với khẩu vị rủi ro của họ, thay vì áp đặt một giải pháp duy nhất.

💡 Bài học đúc rút (Key Takeaway): Giá trị lớn nhất của một BA/EA kỳ cựu không nằm ở việc trả lời đúng câu hỏi khách hàng đặt ra, mà ở việc đặt ra câu hỏi khách hàng chưa nghĩ tới hỏi. Người báo động sớm một rủi ro chưa xảy ra, khi chưa ai yêu cầu, mới là người khách hàng thật sự muốn giữ lại cho những dự án tiếp theo — vì đó là bằng chứng bạn đang bảo vệ lợi ích của họ, không chỉ hoàn thành đúng những gì được viết trong hợp đồng.

🔗 Kỹ năng liên quan

• Tư duy TCO (Total Cost of Ownership) — nhìn xa hơn chi phí ban đầu để đánh giá đúng gánh nặng vận hành và rủi ro dài hạn.
• Tư duy kiến trúc mở — thiết kế hệ thống tránh phụ thuộc cứng vào một nhà cung cấp duy nhất.
• Xử lý sự cố bất ngờ — kỹ thuật thông báo tin xấu minh bạch khi rủi ro đã thành sự cố thật.

Bài trước: Tư duy TCO (Total Cost of Ownership) · Bài tiếp theo: Tư duy kiến trúc mở