Nhận diện các rủi ro trong dự án công nghệ thông tin

Hiện nay, sự phát triển của hệ thống công nghệ thông tin tại Việt Nam đang diễn ra vô cùng mạnh mẽ. Tuy nhiên sự phát triển vượt bậc này không chỉ mang tới những lợi ích cho doanh nghiệp mà còn đem lại những thách thức khó lường. Chia sẻ thuộc chuỗi bài Quản trị rủi ro dự án công nghệ thông tin (CNTT) – Ứng dụng thực tế tại FPT IS, khối Tài chính ngân hàng giúp cho các doanh nghiệp có cái nhìn tổng quan về cách thức nhận diện rủi ro trong các dự án CNTT để có phương thức phòng ngừa kịp thời cũng như chuẩn bị sẵn các biện pháp khắc phục trong trường hợp rủi ro xuất hiện 

 Việc triển khai dự án đòi hỏi doanh nghiệp hiểu được thế nào là rủi ro dự án. Sự thành công trong quản trị dự án tại FPT IS được xem như một bài học kinh nghiệm trong thực tế để trả lời cho các câu hỏi sau:

• Làm thế nào để nhận diện hết các rủi ro trong dự án?
• Tất cả các rủi ro đều được đưa vào kế hoạch hành động hay không? 
• Làm thế nào để cân đối hài hòa giữa quản trị rủi ro và chi phí
• Một số biện pháp phòng ngừa rủi ro cơ bản

1. Xác định rủi ro như thế nào?

Hỏi: Nhiều Quản trị dự án khi tiếp nhận dự án, họ cũng rất muốn thực hiện quản trị rủi ro đúng theo lý thuyết của Quản trị rủi ro, mà thường lúng túng và không biết bắt đầu từ đâu để xác định các rủi ro trong dự án. Vậy các chị thường bắt đầu xác định rủi ro như thế nào?

Đáp: FPT IS thường bắt đầu tìm kiếm rủi ro từ nguồn đầu tiên là hợp đồng (HĐ) và sau đó là các hồ sơ khác liên quan đến quá trình trước khi ký Hợp đồng. Tiếp sau đó, đội dự án của chúng tôi cùng với doanh nghiệp (sau đây gọi tắt là khách hàng) sẽ tiếp tục thu thập các thông tin về rủi ro từ các bên liên quan như nhân sự dự án mỗi bên, từ mô hình tổ chức sự ưu tiên của mỗi bên đối với dự án…, cụ thể thế này:   

• Đọc/nghiên cứu toàn bộ hồ sơ dự án. Hồ sơ cơ bản nhất thường là hợp đồng. Chúng ta thường tìm thấy các rủi ro về thời gian, về kỹ thuật, về nghiệp vụ hay về con người khi đọc các tài liệu này. Ngoài ra, các tài liệu trước ký Hợp đồng như thỏa thuận trước khi ký HĐ, yêu cầu thầu, các giải pháp chào giá … cũng là một nguồn quan trọng để có thể tìm thấy khá nhiều rủi ro trong đó. Thông thường, tại đây ta sẽ nhặt được các rủi ro đến từ việc lệch kỳ vọng giữa yêu cầu ban đầu của bên A và giải pháp do bên B mang đến bởi rất có thể, những người đưa yêu cầu thầu ban đầu họ chưa thế hình dung được giải pháp bên B mang đến sẽ đáp ứng cụ thể yêu cầu ban đầu của họ như thế nào nên trong đầu họ vẫn luôn chỉ có yêu cầu ban đầu.

Có nhiều các thỏa thuận với khách hàng được ký ở mức diện rộng, còn lớn hơn cả phạm vi triển khai của dự án là tiền đề để ký kết hợp đồng hiện tại, hoặc thậm chí có nhiều yêu cầu được đưa dưới dạng nền tảng căn bản tại các văn bản trước HĐ hiện tại và được coi là điều phải đáp ứng hiển nhiên nên không được đưa lại vào trong HĐ và/hoặc không được chỉ ra trong các tài liệu yêu cầu thu thập – phân tích yêu cầu chi tiết. Nếu biết được những điều này từ ngay từ khi sớm, các rủi ro về việc không thể chỉnh sửa hệ thống hoặc mất nhiều chi phí để chỉnh sửa hệ thống ở các giai đoạn UAT hoặc ở các hợp đồng nâng cấp sau này sẽ được lập Phương án phòng ngừa ngay từ đầu và tạo ra 1 hệ thống quản trị rủi ro rộng lớn hơn ở mức độ tổ chức cho chính các khách hàng sử dụng sản phẩm/dịch vụ này. 

Trong trường hợp chúng ta mua sản phẩm của hãng và có thể thuê hãng hay 1 vài nhà thầu phụ nào đó tham gia vào hoạt động triển khai, thì các hợp đồng/thỏa thuận hợp tác giữa chúng ta và các nhà thầu phụ/hãng đó cũng cần được nghiên cứu một cách chi tiết. Hãy tìm các điểm vênh trong thỏa thuận giữa hợp đồng chính ký với khách hàng và hợp đồng/thỏa thuận với hãng/các nhà thầu phụ. Dự án chỉ có thể “tạm an toàn” (hay nói cách khác là chúng ta “tạm an tâm”) nếu như toàn bộ yêu cầu của khách hàng đều được chuyển tải toàn bộ sang các hợp đồng/thỏa thuận với hãng theo nguyên tắc “không sai một chữ” nhất là khi chúng ta không phải là bên làm chủ về công nghệ/nghiệp vụ/giải pháp. Sẽ an toàn hơn nữa nếu dự án thể hiện rằng mọi thỏa thuận với hãng/thầu phụ luôn rộng hơn thỏa thuận với khách hàng.

Trước đây, tôi đã từng triển khai 1 dự án có ký thỏa thuận với hãng cung cấp licence cho 1 phần mềm ứng dụng. Khi đọc đến thông số chi tiết về cung cấp licence của hãng, tôi chỉ hiểu được 1 phần rất nhỏ và khi cố gắng đối chiếu đáp ứng với yêu cầu của khách hàng, tôi tạm yên tâm vì thấy có thể suy luận những thông tin mà tôi hiểu trong hợp đồng với hãng là có thể đáp ứng yêu cầu của khách hàng. Sau đó, ngay trước khi golive hệ thống chỉ vài tuần, tôi mới phát hiện ra rằng, tất cả những gì mà tôi hiểu trước đó trong thông số kỹ thuật của hãng được nêu trong hợp đồng ký với hãng, chỉ đáp ứng 1 phần yêu cầu của khách hàng, phần còn lại hoàn toàn không đáp ứng. Lần lại các hồ sơ trao đổi làm rõ licence với hãng trong quá trình làm thầu, tôi phát hiện ra rằng các nội dung trao đổi làm rõ thông số kỹ thuật đã được đội làm thầu trao đổi chi tiết với hãng và hãng trả lời hoàn toàn đáp ứng 100% yêu cầu của khách hàng. Tuy vậy, không hiểu vì sao trong quá trình lập hợp đồng với hãng, các nội dung yêu cầu chi tiết của khách hàng không được chuyển tải sang mà viết dưới dạng thông số kỹ thuật. Vụ việc này ảnh hưởng nghiêm trọng đến tài chính của dự án và thời điểm golive của hệ thống. Vậy nên tại sao đến giờ, tôi vẫn đang trung thành với nguyên tắc “không sai một chữ” đã nói ở trên. 

• Việc làm việc với đội làm thầu cũng là một mấu chốt quan trọng mà chúng tôi thường không bỏ qua trong quá trình định vị rủi ro. Điều này vừa giúp đội dự án nhanh chóng tiếp cận mục tiêu xây dựng dự án của bên A, vừa giúp tìm thấy các vấn đề và rủi ro đang hiện hữu một cách nhanh chóng nhất. Có nhiều các nội dung trao đổi, làm rõ các điểm/thuật ngữ không phổ cập giữa các bên được trao đổi bằng email, bằng tin nhắn… hoặc qua bất kỳ các kênh trao đổi không chính thức nào giữa đội tư vấn thầu và khách hàng/hàng/thầu phụ bị bỏ qua không đưa vào hợp đồng. Việc thu thập đầy đủ các thông tin này giúp cho chúng ta có đủ nguyên liệu để đánh giá các rủi ro có thể xảy ra với dự án trong tương lai. Vậy nên, ngay từ khi nhận hợp đồng và nghiên cứu hợp đồng, chúng tôi liên tục thiết lập các buổi làm việc với đội thầu và liên tục giữ kết nối với đội này ngay cả trong giai đoạn triển khai của dự án. 
• Nói chuyện/làm việc với đội nghiệp vụ, kỹ thuật của dự án của mình để đánh giá năng lực chuyên môn, năng lực quản trị của các thành viên dự án nhằm tìm ra các rủi ro về con người từ chính những thành viên đội dự án. Ngoài ra, việc nói chuyện cá nhân với họ (qua bất kỳ cuộc trao đổi nào: họp chính thức, các buổi làm việc hoặc đơn giản chỉ là các câu chuyện “trà đá vỉa hè”) cũng giúp Quản trị dự án có thể xác định được mức độ của họ gắn kết, mức độ tin tưởng và thoải mái của họ với dự án và với các thành viên khác trong đội. Họ có thể rất giỏi về chuyên môn và việc họ không chuyên tâm cho dự án có thể là một tín hiệu của rủi ro, tương tự việc chia sẻ 1 nguồn lực tại một thời điểm cho nhiều dự án cũng vậy. Việc họ có thể có các bất mãn ngấm ngầm với các thành viên khác trong đội cũng sẽ ảnh hưởng đến tiến độ chung và là rủi ro về mặt nhân sự. Ngoài ra, bản thân các thành viên dự án sẽ cung cấp cho chúng ta những điểm mà họ nhìn thấy trong dự án mà Quản trị dự án, thậm chí các team lead cũng không nhìn thấy hoặc bị bỏ qua. Từ các thông tin này, quản trị dự án có thể thấy tìm thấy các rủi ro về mặt nghiệp vụ, kỹ thuật hoặc giải pháp. 
• Nói chuyện/làm việc với các nhân sự chủ chốt của khách hàng và nhà thầu/hãng cũng giúp chúng ta tìm thấy các rủi ro đến từ chuyên môn (nghiệp vụ, kỹ thuật…) của họ, mức độ hiểu biết của họ về dự án, về yêu cầu. Quan trọng hơn cả là việc này giúp chúng ta xác định các rủi ro đến từ phía tổ chức của họ. Thông thường, các nhân sự nghiệp vụ/kỹ thuật của khách hàng thường thuộc về 1 phòng ban nào đó, và giờ họ được cử tham gia dự án có thể dưới dạng là việc làm thêm trong lúc rảnh rỗi. Việc tổ chức không coi tham gia dự án là công việc chính thức đối với nhân viên, thậm chí không tính KPI cho nhân viên về việc này là một rủi ro đối với tiến độ và chất lượng của sản phẩm. 
• Xác định thêm các thông tin chính sách/kế hoạch ở mức độ tổ chức của khách hàng/hãng để làm rõ việc dự án có đang đủ điều kiện cơ bản để vận hành thành công không. Nhiều dự án buộc phải dừng, hủy do thiếu điều kiện cơ bản để triển khai thành công một dự án công nghệ thông tin như: đội dự án các bên phải cùng chung mục đích, hay thiếu người bảo trợ cho dự án một cách hiệu quả… Các vấn đề hay gặp hơn là nhiều chính sách/kế hoạch của bên khách hàng (như thay đổi 1 hệ thống core đang chạy ổn định có dự định đấu nối, tích hợp với hệ thống bạn đang triển khai) hoặc hãng (như có kế hoạch dừng hỗ trợ cho những công cụ/giải pháp bạn đang sử dụng để triển khai dự án) đều là các rủi ro đối với dự án.  Việc khách hàng hiện có 1 dự án quan trọng hơn đang chạy song song cùng với dự án của chúng ta và cùng có cạnh tranh về nguồn lực thì đó có thể sẽ là rủi ro lớn đến việc hoàn thành dự án đúng hạn hay đủ chất lượng. Vậy nên, nếu có thể được, hãy nhờ mọi mối quan hệ để có thể xác định mức độ quan trọng của dự án hiện tại với các dự án khác/công việc khác trong tổ chức của khách hàng. Việc này sẽ không phải là dễ khi bạn ở vị trí một quản trị dự án, tuy nhiên, cũng không phải là một việc bất khả thi nếu bạn chủ định tìm hiểu.  
• Xác định thêm các thông tin chính sách ở cấp độ ngành/quốc gia nhằm xác định rõ có sự thay đổi trong ngắn và trung hạn về luật định, về thông tư nghị định hướng dẫn cho mảng nghiệp vụ bạn đang triển khai tại dự án hay không. Với những dự án bị kéo dài hoặc phát sinh phạm vi triển khai thì việc không khoanh vùng được phạm vi triển khai trong thời gian triển khai là một trong những nguyên nhân cơ bản. 

2. Cách thức thực hiện dự án hiệu quả

Hỏi: Các chị thường làm việc đó một mình hay yêu cầu mọi thành viên dự án tham gia? Và nếu rơi vào 1 dự án mà Quản trị dự án chưa có nhiều kinh nghiệm trước đó thì phải giải quyết làm sao?

Đáp: Các quản trị dự án FPT IS thường không làm việc đó một mình mà làm chung với các nhân sự chủ chốt về nghiệp vụ, kỹ thuật có trong dự án thông qua hoạt động Brainstorming. Chúng tôi thường không giao việc này cho tất cả thành viên dự án do 1 số bạn quá trẻ, chưa có kinh nghiệm. Giao việc cho các bạn việc này thường dẫn đến các bạn bị rối và Ban Quản lý dự án mất nhiều thời gian để sàng lọc để tìm ra các thông tin thực sự có giá trị. 

• Sử dụng biện pháp Brainstorming để tìm ra các rủi ro một cách nhanh nhất trong thời gian ngắn hoặc trong lĩnh vực dự án mà Quản trị dự án không có nhiều kinh nghiệm chuyên môn. Chúng tôi thường hay áp dụng biện pháp này với 2 giai đoạn nhỏ: (1) brainstorming với các nhân sự chủ chốt của dự án để tìm thấy hết các điểm có thể là vấn đề/chứa đựng rủi ro 🡪 (2) xin ý kiến với các chuyên gia có kinh nghiệm về loại dự án/sản phẩm/giải pháp này. 

Hỏi: vậy nếu trong trường hợp các quản trị dự án cũng không biết chuyên gia nào có thể tham gia đánh giá được thì sao?  

• Vậy đơn giản hãy đưa nhu cầu cần chuyên gia review với Giám đốc dự án của bạn hoặc giám đốc đơn vị chủ quản của dự án để họ tìm giúp bạn. Tổ chức luôn sẵn sàng hỗ trợ bạn khi bạn cần. Cũng trong 1 số trường hợp, dự án cũng không thể tìm được các chuyên gia có kinh nghiệm để thẩm định các rủi ro/vấn đề mà đội dự án tìm ra, vậy hãy tạm thời ghi nhận đến hiện tại và liên tục theo dõi, đánh giá trong quá trình triển khai dự án khi có các tín hiệu rõ ràng hơn. 

3. Khi nào doanh nghiệp cần nhận diện rủi ro?

Hỏi: Việc nhận diện rủi ro chỉ cần làm ở giai đoạn đầu của dự án?

Đáp: việc nhận diện rủi ro cần làm ở giai đoạn đầu dự án và tiếp tục thực hiện trong quá trình triển khai dự án: 

• Liên tục rà soát tình trạng thực hiện dự án và điều chỉnh danh sách rủi ro, điều chỉnh các Phương án khắc phục, phòng ngừa là việc của quản trị dự án cần thực hiện. Chúng ta chắc chắn không thể chỉ duy nhất có 1 danh sách rủi ro bất di bất dịch được xác định ở thời điểm đầu dự án mà các rủi ro sẽ rõ dần hoặc mờ dần trong suốt quá trình triển khai khi có thêm các thông tin hoặc thậm chí là do chúng ta triển khai các hoạt động phòng ngừa/khắc phục một hay 1 nhóm các rủi ro/vấn đề nào đó.   

Hỏi: Với các cách mà các chị nêu trên, các chị có tự tin tìm ra hết các rủi ro trong lần nhận diện đầu dự án?

Đáp: Cách này giúp chúng tôi có thể nhận diện ra số lượng rủi ro lớn nhất có thể ở đầu dự án, còn không thể giúp nhận diện ra toàn bộ các Rủi ro có trong dự án. Chính vì vậy, việc liên tục rà soát tình trạng dự án là để tiếp tục phát hiện các rủi ro mà mình chưa phát hiện trước đó. Thậm chí, có những rủi ro mà thực tế ngay từ đầu dự án chưa có, nó chỉ xuất hiện khi dự án có thêm các nhân tố mới trong quá trình triển khai dự án.