Sự thất bại của dự án phần mềm và vấn đề tăng sự dự án (Problem of Project Escalation)

Các dự án công nghệ thông tin (CNTT) có tỷ lệ thất bại cao nhất trong các loại dự án, đặc biệt là dự án lập trình phần mềm. Không giống các dự án xây dựng, công trình, đóng tàu... một đặc tính quan trọng của phần mềm là không thấy, không sờ được. Mọi người chỉ thấy được sự tồn tại của phần mềm khi được đem ra sử dụng. Vì tính trừu tượng này sẽ phát sinh ra nhiều nguyên nhân mà đa số là nguyên nhân chủ quan dẫn tới thất bại của dự án. Có nhiều nguyên nhân gây ra sự thất bại của dự án. Có nguyên nhân của chủ đầu tư (bên A), có nguyên nhân của đối tác gia công lập trình phần mềm (Bên B).

Các dự án công nghệ thông tin (CNTT) thất bại vì bất kỳ lý do nào và trong một số trường hợp có thể dẫn đến tổn thất tài chính đáng kể cho các tổ chức. Một dạng thất bại ít được quan sát là dự án CNTT dường như tiếp tục kéo dài, tiêu tốn các nguồn tài nguyên mà không đạt được mục tiêu. Phần lớn các dự án này cuối cùng sẽ thất bại, có khả năng làm suy yếu vị thế cạnh tranh của công ty đồng thời bòn rút các nguồn lực có thể dùng để phát triển và triển khai các hệ thống thành công khác. Các tài liệu báo cáo tăng sự (Escalation) trong quá trình làm dự án là căn cứ quan trọng để giải thích loại lỗi CNTT này. Căn cứ vào các cam kết liên tục gia tăng nhưng không được thực hiện dựa trên tài liệu dự án, nghiên cứu tình huống (Case Study) cho thấy rằng sự thất bại của dự án gây ra bởi sự kết hợp của các yếu tố hình thành dự án, tâm lý (ví dụ thành kiến - bias), nghịch lý xã hội và tổ chức. 

Có nhiều nguyên nhân gây ra sự thất bại của dự án. Có nguyên nhân của chủ đầu tư (bên A), có nguyên nhân của đối tác gia công lập trình phần mềm (Bên B).

Sai lầm của nhà đầu tư (hoặc đơn vị thụ hưởng)

Sau đây chúng tôi xin liệt kê các nguyên nhân từ bên chủ đầu tư.

Nhận thức sai về phần mềm

Nhận thức sai về phần mềm là nguyên nhân hàng đầu. Khách hàng không rõ dùng để làm gì, giải quyết bài toán nào trong doanh nghiệp.

Nhiều chủ doanh nghiệp ảo tưởng về việc ứng dụng, coi phần mềm là "đũa thần" hoặc "viên đạn bạc" (silver bullet) giải quyết mọi vấn đề của doanh nghiệp, kể cả việc tăng doanh số và lợi nhuận. Thực tế phần mềm chỉ là công cụ giúp cho bộ máy doanh nghiệp hoạt động tốt hơn mà thôi.

Và vì ôm đồm, chủ doanh nghiệp vẽ ra bức tranh hoành tráng, ứng dụng vào mọi ngóc ngách của doanh nghiệp. Trong khi doanh nghiệp chưa chuẩn hóa quy trình, hoạt động chưa ổn định, nhân viên nghỉ việc liên tục.

Hãy nghĩ tới phần mềm khi doanh nghiệp của bạn hoạt động không hiệu quả với Excel cũng như trải qua nhiều "niềm đau" (pain points) khi giải quyết khối lượng lớn các công việc xử đống giấy tờ hàng ngày. Lúc này lập trình phần mềm sẽ giúp doanh nghiệp chuẩn hóa quy trình hiện có một cách nhanh chóng, chính xác và tiết kiệm nhân lực.

Lấy một thí dụ cụ thể, vào tháng 5/2022 khi TIGO PoC Team đi khảo sát một đơn vị Logistics và chúng tôi tập trung vào các vấn đề xoay quanh hiện trạng (AS-IS) của các phần mềm mà doanh nghiệp đã sử dụng. Chúng tôi nhận thấy rằng, bộ phận "Triển khai" đã phải trải qua một quá trình "đau đớn khủng khiếp" khi có hàng ngàn email gửi đến mỗi ngày trong khi nguồn lực rất hạn chế, dẫn đến một vấn đề nghiêm trọng là "rất nhiều email quan trọng của đối tác đã bị 'missed' hoặc được phản hồi khá chậm trễ". Sau 2 ngày khảo sát và phân tích các giải pháp khả thi, hai bên đi đến một giải pháp khá kịp thời trong giai đoạn nước sôi lửa bỏng: "Thiết kế một giải pháp lọc nội dung tự động và chuyển tiếp thư tự động cho những người được phân công". Đây là một giải pháp thiết thực, mang lại giá trị tức thời cho doanh nghiệp, tiết kiệm chi phí và không ảnh hưởng kế hoạch toàn diện trong dài hạn.

Chủ doanh nghiệp không quan tâm sâu sát

Nhiều người cho rằng chỉ cần chi tiền mua là xong. Phần mềm tốt cho doanh nghiệp, tốt cho mọi người nên mọi người sẽ vui vẻ đón nhận.

Tuy nhiên việc áp dụng lập trình phần mềm vào doanh nghiệp sẽ làm thay đổi cách thức làm việc cũ, điều mà hầu như tất cả nhân viên đều không muốn: “Đang yên ổn dùng phần mềm mới làm gì”. Hoặc sau khi triển khai phần mềm, thống kê cho thấy phần mềm có thể dẫn đến "thêm việc" cho nhân viên. Doanh nghiệp cảm thấy bận rộn hơn trước, thời gian dành cho vận hành các hệ thống CNTT ngày càng lấn lướt thời gian dành cho chuyên môn chính.

Phần mềm sẽ làm minh bạch các thông tin và không phải nhân viên nào cũng muốn minh bạch. Vì thế khi triển khai cần có một sức mạch quyền lực để áp đặt, để lôi kéo và động viên. Tức là lãnh đạo doanh nghiệp cần sâu sát vào toàn bộ quá trình chuyển đổi đầy khó khăn này. Vì suy cho cùng, mục tiêu cuối cùng tối thượng của phần mềm là phục vụ doanh nghiệp, phục vụ ông chủ!

Phần mềm giúp chủ doanh nghiệp quản lý, theo dõi điều hành và ra quyết định. Nhưng 100% người vận hành lại là nhân viên, vì thế có sự khác biệt giữa mong muốn kỳ vọng của ông chủ với những khó khăn mà nhân viên gặp phải khi triển khai. Ông chủ hoặc các lãnh đạo đưa nhiều ý tưởng vào nhưng không trực tiếp vận hành nên sẽ có khoảng trống giữa lý thuyết và thực tế.

Chủ đầu tư thay đổi yêu cầu liên tục

Việc chủ đầu tư thay đổi yêu cầu, thêm các chức năng mới hoặc thay đổi quy trình nghiệp vụ gây ra khó khăn cho việc hoàn thành phần mềm. Thường các công ty có quy trình quản lý chuẩn mới nên viết phần mềm.

Phần mềm chỉ là bước chuyển hóa từ quy trình thủ công lên quy trình quản lý bằng máy tính với công nghệ mới, thiết bị mới như Web, app nhằm tăng tốc độ xử lý, chính xác trong các báo cáo.

Nếu doanh nghiệp chưa chuẩn hóa quy trình, việc viết phần mềm sẽ thất bại do khi lấy yêu cầu thì quy trình A, khi viết xong thì đổi thành quy trình B, khi sửa xong quy trình B thì công ty lại dùng quy trình C.

Ngoài ra các nghị định, chính sách khi bắt đầu có hiệu lực cũng chưa thể triển khai tương ứng trên các hệ thống phần mềm. Quy trình phân tích nghiệp vụ sẽ mô hình hóa các chính sách mới, chuyển hóa thành tính năng trên phần mềm. Trong nhiều trường hợp, dự án thất bại do nghiệp vụ mới chưa đủ thông tin để đi vào phần mềm.

Các bộ phận tham gia không đồng lòng

Các dự án ứng dụng CNTT thường liên quan đến nhiều bộ phận và cá nhân trong tổ chức. Nhiều ứng dụng CNTT còn có liên quan đến cả các cơ quan, tổ chức cá nhân ở bên ngoài (cung cấp dịch vụ công trực tuyến, một cửa điện tử liên thông…).

Chỉ cần một bộ phận không hiểu, không tham gia, không đồng lòng, không cùng được đào tạo, huấn luyện đầy đủ thì sự gẫy vỡ ở một khâu có thể làm sụp đổ cả một hệ thống.

Ví dụ phần mềm hoạt động rất ổn cho các phòng ban, riêng phòng kế toán có vấn đề, người ta lại phải làm động tác rút trích dữ liệu từ phần mềm ra riêng cho phòng kế toán.

Lâu ngày việc này sẽ làm thay đổi dòng chảy thông tin, mọi người sẽ có xu thế chuyển thẳng dữ liệu cho phòng kế toán thay vì đưa vào lập trình phần mềm rồi lại phải xuất dữ liệu ra cho kế toán.

Cuối cùng thì phần mềm càng ít người cập nhật thông tin và dẫn đến việc loại bỏ khỏi hoạt động doanh nghiệp.

Không đầu tư vào quá trình vận hành

Việc đầu tư phần mềm cho doanh nghiệp không giống mua một chiếc máy in. Mua xong về gắn dây là dùng. Phần mềm trong suốt qua trình vận hành phải có đội ngũ bảo trì, vận hành, hỗ trợ. Đối với các dụ án đầu tư công, đa số các địa phương (tỉnh, thành) triển khai các gói dự án hàng năm dành cho bảo trì, bảo dưỡng và nâng cấp các tính năng. Lý do là phần mềm cũng giống như máy móc, sau một thời gian không bảo dưỡng sẽ gặp nhiều sự cố như: tốc độ load chậm hơn (do dữ liệu ngày càng lớn), khó kiểm soát các hoạt động của người dùng nếu lượng tương tác tăng theo thời gian... Các hoạt động bảo dưỡng phần mềm không phải là "tra dầu máy" hay lau chùi server, mà sẽ bao gồm các hoạt động như: dọn dẹp dữ liệu tạm (data cleanup), cắt log (database), backup database, backup files, di chuyển dữ liệu cũ (archive) sang Server khác để giảm tải cho Server chính...

Doanh nghiệp sau khi mua phần mềm lại thiếu nhân viên phụ trách CNTT có đủ trình độ để quản trị hệ thống. Không có người hỗ trợ nhân viên trong quá trình sử dụng, khắc phục sự cố sau khi triển khai phần mềm.

Đây cũng là nguyên nhân dẫn đến sự không bền vững của dự án. Việc này có thể khắc phục bằng cách ký hợp đồng bảo trì với bên cung cấp phần mềm.

Đầu tư viết phần mềm nửa vời

Đầu tư không tới là một nguyên nhân thường thấy. Dự án ứng dụng phần mềm đòi hỏi phải được đầu tư đồng bộ cả về phần cứng, phần mềm, đào tạo chuyển giao, vận hành.

Do đó, kinh phí cần phải được cấp đủ, trong một khoảng thời gian tối đa là 1 năm để có thể thực hiện được đồng bộ việc lắp đặt thiết bị, cài đặt và chuyển giao công nghệ.

Tuy nhiên, hiện nay rất nhiều người cho rằng viết phần mềm không tốn nhiều tiền chỉ vài ba chục triệu mua phần mềm, mà không biết có hiệu quả không. Phần mềm cứ làm từ từ xem thế nào, mọi thứ cũng đang tạm ổn. Và với năng lực CNTT của Việt Nam đang rất thấp ở khu vực, thì hiện tượng "thầy bói xem voi" diễn ra ở khắp mọi nơi: Có người nghĩ phần mềm chỉ 100 triệu, có người lại cho rằng phần mềm mặc định phải kết nối được các phần mềm họ đang dùng (ví dụ zalo, facebook...), thậm chí các doanh nghiệp nhỏ và vừa chỉ xem phần mềm ERP trị giá triệu đô la như phần mềm Website.

Kết quả là nhiều dự án CNTT được cấp kinh phí “nhỏ giọt”, dự án được thực hiện từng phần trong khoảng thời gian dài dẫn đến hệ thống khi được đầu tư đủ thì sẽ thiếu đồng bộ làm ảnh hưởng đến mặt kỹ thuật, hiệu quả dự án, gây ra chán nản cho nhân viên tham gia dự án.

Sai lầm của nhà thầu triển khai phần mềm

Dưới đây là những nguyên nhân từ phía công ty phần mềm:

Dự toán sai

Việc lên dự toán sai sẽ dẫn đến báo giá sai, ước lượng thời gian hoàn thành dự án sai. Việc dự đoán sai thường do người lấy yêu cầu không đủ kinh nghiệm.

Đánh giá sai một vài chức năng trong hệ thống, hoặc đánh giá sai phần cốt lõi. Ví dụ khách hàng yêu cầu viết phần mềm đếm số lượng ô tô ra vào nhà máy thì cái khó nằm ở chỗ phân biệt xe tải, xe con, xe đi sát nhau. Mà yêu cầu doanh nghiệp là phải đếm chính xác không sai sót. Nếu chọn công nghệ nhận dạng vào bài toán này sẽ dẫn đến bế tắc. Công nghệ nhận dạng hiện nay khó có thể đạt tới mức độ chính xác trên 95%.

Nhân lực triển khai dự án phần mềm không đủ năng lực

Để triển khai phần mềm thành công, đội ngũ triển khai phải có sự hiểu biết ở cả lĩnh vực phần mềm và kiến thức chuyên môn nghiệp vụ doanh nghiệp. Đội ngũ triển khai này có vai trò như cầu nối giữa doanh nghiệp và đội ngũ phát triển phần mềm.

Trong rất nhiều dự án phần mềm, đội ngũ tham gia triển khai các dự án là nhân viên CNTT không hiểu biết về chuyên môn, hoặc người có chuyên môn cao am hiểu nghiệp vụ thì không am hiểu về CNTT.

Phân tích yêu cầu sai hoặc thiếu sót

Tiến sĩ Remer, chủ tịch của Claremont Consulting Group, đã kiểm tra với hàng trăm dự án rộng khắp các ngành công nghiệp và các tổ chức chính phủ trong hơn 30 năm. Nghiên cứu của ông khẳng định sự cần thiết để làm đúng ngay đầu vì chi phí sửa lỗi sau này tăng rất lớn. Quy luật là “chi phí sẽ tốn gấp 10 lần để sửa chữa vấn đề ở mỗi giai đoạn sau của dự án”. Ví dụ, nếu chi phí để sửa chữa vấn đề trong giai đoạn lập kế hoạch là $10.000, thì sẽ mất $100.000 để sửa chữa trong giai đoạn thiết kế và mất $1.000.000 để sửa trong giai đoạn triển khai (implementation, coding). Và nếu phần mềm đi vào vận hành (go-live) nhiều lỗi tiềm ẩn thì chi phí bảo trì, khắc phục ... là một con số không hề nhỏ.

Phạm vi công việc bị leo thang mất kiểm soát (Scope Sreep)

Nguyên nhân chính là do người quản lý không đủ kỹ năng nói “không” với khách hàng để bảo vệ phạm vi dự án. Một nguyên nhân nữa là không có quy trình quản lý thay đổi tốt để kiểm soát được phạm vi hay điều chỉnh các ràng buộc, mục tiêu tương ứng một cách hợp lý khi có thay đổi.

Các quản lý dự án dễ bị rơi vào bẫy "tưởng đơn giản mà hóa phức tạp". Thậm chí các thay đổi (CR - Change Request) là nhỏ, nhưng 100 CR sẽ khiến cho toàn bộ vòng đời dự án bị tổn thương nặng nề, ảnh hưởng tiến độ Go-Live và rủi ro cao nhất là ảnh hưởng mạnh đến tổng chi phí dự án. Khi được báo hiệu trước về "rủi ro lỗ", các kỹ sư phần mềm sẽ mất động lực làm việc khi luôn nhận được cảnh báo về các sai lầm mà tưởng như chỉ có các quản lý dự án mới phải gánh chịu.

Không lưu ý các rủi ro "tắc nghẽn" có thể xảy ra với các điều khoản hợp đồng

Dự án càng lớn, thì càng phát sinh nhiều bất đồng về cách thực hiện dự án cũng như phạm vi lợi ích giữa các bên như: liên tục thay đổi yêu cầu ("đẽo cày giữa đường"), thay đổi hợp đồng, thay đổi ngân sách dự án, tranh chấp bản quyền phần mềm, tranh chấp source code... Về phía đơn vị phát triển vì muốn tránh dự án lỗ nên việc từ chối của họ sẽ khiến các bên nghĩ rằng đây là hành vi "né việc, đốt cháy giai đoạn, rút ruột các hạng mục trong phụ lục...". Những bất đồng này nếu không được xử lý dứt điểm bởi các lãnh đạo cấp cao liên quan, dự án có rủi ro chậm tiến độ, giảm chất lượng công việc, làm xói mòn niềm tin giữa các bên...

Giảm cam kết trong các dự án phần mềm thất bại

Thông qua việc giảm dần cam kết (DoC - De-escalation Of Commitment), các dự án phần mềm có triển vọng thành công kém có thể bị bỏ rơi một cách hợp lý và các nguồn lực quý giá sẽ được chuyển sang mục đích sử dụng hiệu quả hơn. Mặc dù tầm quan trọng của nó nhưng có rất ít nghiên cứu về các yếu tố góp phần tạo nên DoC trong các dự án phần mềm. Sử dụng thử nghiệm trong phòng thí nghiệm, nghiên cứu này điều tra tác động của các cá nhân (cấp trên và đồng nghiệp) và cách tiếp cận (đổ lỗi và đưa ra sự đảm bảo) đối với DoC trong các điều kiện khác nhau về chi phí chìm (cao hay thấp?).

Kết quả cho thấy, trong điều kiện chi phí chìm thấp, cấp trên giúp đổ lỗi (chiến lược che chở - the shelter strategy) hoặc đưa ra sự đảm bảo (chiến lược hỗ trợ - the support strategy) dường như rất hữu ích trong việc tạo điều kiện thuận lợi cho DoC. Những người ngang hàng giúp đổ lỗi (chiến lược chia sẻ - the sharing strategy) hoặc đưa ra sự đảm bảo (chiến lược thông cảm - the sympathy strategy) cũng tỏ ra hữu ích trong việc tạo điều kiện thuận lợi cho DoC, trong đó chiến lược trước đây đặc biệt hiệu quả. Nhưng trong điều kiện chi phí chìm cao, dường như không có chiến lược nào trong số bốn chiến lược này có thể tạo điều kiện thuận lợi cho DoC.

Chỉ lập kế hoạch một lần (kế hoạch "chết")

Cũng giống như tài liệu (tài liệu sống, tài liệu chết), kế hoạch dự án sẽ bị “mốc” nếu bạn không cập nhật nó thường xuyên. Vì điều kiện thay đổi theo thời gian, chúng cần phải được cập nhật để phản ánh những điều kiện mới và tiến độ thực hiện. Các quản lý dự án thường ngại cập nhật kế hoạch, hoặc quá tập trung vào chuyên môn mà quên mất rằng "tư duy hệ thống" mới là yếu tố sống còn cho sự thành công của dự án.

Việc cập nhật còn hơn cả viêc giám sát chi phí và tinh chỉnh lịch trình. Cập nhật có nghĩa là định kiểm tra lại môi trường đã thay đổi như thế nào, sau đó sửa đổi chiến lược cốt lõi và kế hoạch chi tiết nếu cần thiết.

Và nhiều rủi ro không lường trước

Trên đây chỉ là những nguyên nhân cơ bản trong số rất nhiều nguyên nhân làm cho việc triển khai dự án ứng dụng phần mềm khó khăn phải đầu tư đến 2,3 lần mới thành công. Có những dự án "tạm treo" để giải quyết khác biệt giữa các bên, có dự án sau khi đi vào vận hành được một thời gian thì "đắp chiếu" do không đạt đủ lượng người dùng (user base), hoặc lực kéo (business traction) quá thấp khiến tỉ suất sinh lời (ROI) không làm hài lòng nhà đầu tư.

Kết luận

Các dự án phần mềm ngày nay phức tạp hơn rất nhiều so với 1,2 thập kỷ trước. Lý do là các phần mềm không còn là chương trình chạy độc lập trên máy tính cá nhân, mà đã tiến hóa trở thành các hệ thống phức tạp với nhiều modules phân tán rộng khắp trên nhiều máy chủ. Bản thân các phần mềm cũng kết nối với các hệ thống bên ngoài, điều này sẽ phụ thuộc chặt chẽ vào quan hệ giữa các đơn vị vận hành các hệ thống khác nhau để chia sẻ dữ liệu, chia sẻ thông tin và quan trọng là đồng hành với nhau.