Tầm quan trọng của QL rủi ro được nói rất rõ: tỉ lệ thành công của các dự án CNTT (theo nghĩa đạt được yêu cầu chất lượng, đúng hạn và không vượt chi) rất không cao, chủ yếu do không có hoặc thực hiện không tốt việc phòng ngừa và xử lý các nguy cơ dẫn đến thất bại hoặc hạn chế thành công của một dự án.

Tuy đây là “kiến thức vỡ lòng” của QL dự án CNTT (hay chính vì nó là “kiến thức vỡ lòng”?) nên trên thực tế việc QL rủi ro đã không được quan tâm đúng mức. Thất bại của các dự án CNTT vẫn xảy ra thường xuyên, từ những thất bại mang lại hậu quả có tính khủng hoảng như “112”, đến hàng loạt đề tài và nhiệm vụ ứng dụng được nói khéo là “hiệu quả chưa cao”! Tỉ lệ cao thường xuyên gặp của thất bại và kém hiệu quả này có lẽ đã làm nảy sinh ý nghĩ coi đó là chuyện “tự nhiên” không tránh khỏi. Thậm chí làm xói mòn uy tín của việc tin học hóa, cũng như niềm tin vào sự nghiệp này. Đây là nỗi bức xúc lớn của những người liên quan đến công cuộc tin học hóa của Việt Nam, đã được nhiều người, trong đó có các chuyên gia về CNTT đề cập nhiều lần và trên nhiều diễn đàn.

Bài viết này xin đề cập một vài biện pháp nhằm QL được rủi ro khi triển khai các ứng dụng CNTT tại nước ta.

Xử lý sớm các nguy cơ

Để QL đượ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ơ đó (gọi là “phòng ngừa rủi ro”). Nếu “phòng” mà không “tránh” nổi, 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 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 như trên, nếu có chiến lược và biện pháp QL rủi ro tốt, 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. Trong một lần trả lời phỏng vấn trên VTV mới đây, “Thần đèn xứ Bắc” Đỗ Quốc Khánh - chuyên gia về di dời công trình và chống lún sụt - đã nói đại ý: nếu các công trình lớn thường xuyên mời chuyên gia giám sát dự phòng lún sập (chi phí dưới một triệu đồng) thì sẽ tránh được sự tốn kém gấp nhiều lần khi phải khắc phục chúng. Điều này cũng đúng cả cho các dự án CNTT.

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ơ.

QL 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.

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ơ.

Theo Pcworld