Sự cố loạn mã máy tính gần đây tại Tacoma, Washington cũng khiến cho các khoản viện trợ tài chính dành cho sinh viên đại học tại Indiana bị "treo" lại, còn lợi nhuận của hãng bán lẻ Ross Stone thì sụt giảm tới 40% sau khi hệ thống theo dõi hàng hoá của hãng này trục trặc. 

Những thảm hoạ kiểu này thường được quy tội cả cho phần mềm tồi. Tuy nhiên, trên thực tế, rất ít khi nguyên nhân chủ chốt là vì lập trình kém. Khi các hệ thống ngày càng trở nên phức tạp thì các thiếu sót về mặt kỹ thuật, hoàn toàn trái với suy nghĩ thông thường, càng giảm đi. Và các trục trặc lúc này thường xảy ra do những nguyên nhân bên ngoài kỹ thuật như quản lý kém, thông tin liên lạc lỏng lẻo và đào tạo chưa đạt yêu cầu. 

Đừng đổ lỗi cho kỹ thuật

"Trong 90% trường hợp, nguyên nhân khiến sập hệ thống là vì những người triển khai xây dựng đã làm không tốt phần việc của họ, công tác đào tạo kém", nhà phân tích Joshua Greenbaum tại Enterprise Applications Consulting tại Berkeley nhận định. 

Các chính phủ, doanh nghiệp và tổ chức ngày một lệ thuộng vào công nghệ nên hậu quả do sự cố phần mềm gây ra thường không nhỏ chút nào. Toàn bộ thực thể đó, kể cả cuộc sống của từng cá thể trong đó - đều đứng chơi vơi bên bờ vực nguy hiểm. Nhiều chuyên gia tin rằng tình huống còn trở nên xấu hơn khi nhiều nhiệm vụ mới được thực hiện tự động hoá bằng máy tính, nhiều hệ thống liên thông với nhau và dựa dẫm vào các máy tính khác. Bạn có thể vượt qua những thách thức kỹ thuật, nhưng vấn đề về con người quản lý thì không dễ dàng như vậy. Và cũng sẽ khó lòng dễ dàng hơn trong tương lai. 

 "Những hạn chế mà chúng ta gặp phải là hạn chế từ phía con người chứ không phải phần mềm. Công nghệ luôn đi trước các chức năng quản lý và cơ cấu điều hành của chúng ta trong nhiều trường hợp." 

Những dự án phần mềm lớn, dù là quản lý hệ thống cung cấp dây chuyền, hệ thống thanh toán tiền lương, giám sát công tác kiểm kê nguồn lực hay chuẩn bị tài chính- thì đều bắt đầu từ sự kỳ vọng lớn lao và những ý định tốt đẹp nhất. Tất cả đều phục vụ cho mục đích tăng cường hiệu quả, độ tin cậy, tiết kiệm chi phí và nâng cao sức cạnh tranh. Các hãng có thể tự phát triển các chương trình phần mềm của riêng mình, gia công thô hoặc mua nguyên cả dịch vụ phần mềm doanh nghiệp của các hãng như SAP, Oracle và PeopleSoft. Lộ trình thực hiện, phương thức tiến hành có thể khác nhau, song mục đích cuối cùng thì hoàn toàn như một. 

Tuy nhiên, điều mỉa mai là thảm hoạ đã bắt đầu manh nha ngay trước cả khi người ta viết ra hoặc cài đặt dòng mã đầu tiên. Các tổ chức bao giờ cũng phải vạch rõ mô hình kinh doanh hoạt động của mình, yêu cầu của họ về tinh giảm các thủ tục nội bộ để trình bày chính xác cho nhóm kỹ thuật của dự án. Nếu quá trình Mô hình hoá này không được thực hiện tốt, nhóm kỹ thuật sẽ phát triển phần mềm theo một hướng khác, trái với mong đợi. "Những dự án kiểu này đòi hỏi một nhà lãnh đạo mạnh mẽ, các nguồn lực tư vấn cực kỳ tài năng và những nỗ lực thực sự tập trung nếu muốn thành công", người phát ngôn của SAP tuyên bố. 

Một công trình nghiên cứu vào năm 2002 do Viện Công nghệ và Chuẩn Quốc gia tiến hành đã cho thấy: sự cố phần mềm khiến nền kinh tế Mỹ thiệt hại tới 59,5 tỷ USD mỗi năm. Trong đó, một phần ba số tổn thất này có thể tránh được nếu công tác kiểm tra và thử nghiệm được cải tiến hơn. 

Sự thiếu hụt một ban  lãnh đạo dự án mạnh mẽ và có tầm nhìn xa trông rộng có vẻ như là nguyên nhân chính trong sự cố của HP, chính vì vậy, ba quan chức hàng đầu của hãng phụ trách về máy chủ và lưu trữ đã bị sa thải chỉ vài giờ sau khi HP công bố kết quả tài chính đáng thất vọng vào ngày 12/8 đen tối. 

Thờ ơ và Thiển cận

 Ngoài ra, những dự án lớn cũng có thể bị huỷ hoại ngầm ngay trong quá trình phát triển, nhất là khi không huy động đủ nguồn lực cần thiết. Những người có trách nhiệm làm việc với hệ thống mới không tham gia vào quá trình lập kế hoạch triển khai còn các quan chức thì chẳng buồn bận tâm. Quá trình trao đổi thông tin hai chiều giữa chủ dự án và các nhà phát triển phần mềm thế là "đi tong" mất một vế."Sai lầm chỉ gây đau, nhưng hiểu lầm có thể làm chết người", John Michelsen, CEO của iTKO nhận định. Gần như trong mọi trường hợp, tất cả những gì các nhà lập trình nhận được chỉ là một bản tài liệu dài ngoằng ngoẵng trình bày các yêu cầu của doanh nghiệp đối với dự án phần mềm. Họ phải tự mình đánh vật với nó, tự "dịch", suy luận và triển khai. Nên nhớ rằng các kỹ sư phần mềm là những người thuần tuý chuyên môn về công nghệ. Họ không được đào tạo để thẩm định các yêu cầu quản lý, hoặc nếu như họ nhận làm gia công thô, thì thậm chí họ còn đến từ một môi trường văn hoá khác. 

Một số hãng khác thì "tiếc cây mà bỏ rừng", vì muốn giảm bớt độ phức tạp của quá trình kiểm tra, thử nghiệm mà các quan chức chẳng-biết-gì-công-nghệ của họ yêu cầu khăng khăng: mã viết ra phải tuyệt đối trung thành với quan điểm do họ đề ra. Hậu quả của sự "tiết kiệm" không phải lối này đã gây ra sự cố ngắt điện hệ thống radio liên lạc trên vùng trời California, Nevada và Arizona vào ngày 14/9 vừa qua. May mà 403 chiếc máy bay đang "rong ruổi" trên bầu trời lúc ấy đã hạ cánh một cách an toàn. 

Một lý do khác cũng tham gia vào sự cố này là khi công tác bảo dưỡng định kỳ bị bỏ qua thì dữ liệu sẽ bị quá tải. Theo thiết kế ban đầu, hệ thống sẽ tự động ngắt khi bộ nhớ bị tràn. Song hệ thống dữ trữ phòng hộ cũng bị hỏng nốt. Tổng cộng, hệ thống liên lạc tại miền Nam California đã tắt đúng 3 giờ đồng hồ. 

Một tác nhân phổ biến khác là trình độ của các nhân viên trực tiếp sử dụng hệ thống. Thường thì họ không được đào tạo đúng cách và đúng theo yêu cầu. Cũng có thể là do họ thực tâm không muốn dự án thành công, nhất là khi họ nghĩ nó đe doạ đến công ăn việc làm của mình.