信息系统项目失败的原因分析及对策

2020-02-02李惠

电子技术与软件工程 2020年17期

李惠

（南京富士通南大软件技术有限公司江苏省南京市 210012）

1 引言

根据PMI（Project Management Institute）的报告Pulse of the Profession 2020，从系统的目标达成（MetGoals）、满足预算(Within budget)、及时交付(On Time)、范围蔓延(Scope creep)、项目失败（Project failures）五个方面看，在各类组织中，信息系统研发和运营方面都存在诸多问题。如果将以上五个方面中的任一方面未达成则视作项目失败的话，则失败率将超过50%。分析项目失败的原因并找出解决方案，对提高项目的成功率尤为重要。

本文将结合笔者的实践，提出一种改进的信息系统项目失败的原因分析模型，并提出基于敏捷软件开发的模型来解决项目失败的问题。

2 信息系统失败原因分析模型

Rajiv Sabherwal 等人提出信息系统成功的个人与组织决定因素中，基于信息系统成功、用户相关和情景相关三个维度，从信息系统购买方（后文统称甲方）的角度进行分析和建模，可以很好地对信息系统是否成功进行评价[1]。但是，该模型忽略了信息系统的提供方（后文统称乙方）和开发过程。对于项目失败的原因分析，不仅要从甲方，也需要从乙方的角度进行分析。笔者结合多年的从业经验，借鉴Rajiv Sabherwal 等人的评价模型，从系统、情景、人员、商务4 个维度出发，结合甲方和乙方的视角进行信息系统失败的原因分析。分析模型如表1所示。

3 信息系统项目失败原因分析

3.1 系统因素

从系统因素出发，主要有如下3 个方面对系统的失败有重大影响。

3.1.1 需求不明确

在过去的几十年里，各企事业单位导入的各种信息系统，大多都借鉴了国外成熟的系统和实施方法，需求相对容易把握。但是最近几年，伴随着数字化技术的发展，需要向数据要价值，这方面还处于探索阶段，且各行各业的数据差异大，甲方的诉求也大不相同，因此需求也相当不明确，导致项目的难度变大。

3.1.2 准备不充分

大多数企业对信息系统寄予了过高的期望，以为导入信息系统可以解决一切问题，比如生产制造企业，以为导入了ERP、MES等系统后，马上可以起到降低库存、提高产能等效果。但实际上，信息系统是帮助客户固化标准流程，可以提高工作效率和资源利用率，而不能从主观上帮助企业梳理业务流程[2]。因此在导入信息系统之前，必须首先对业务流程进行梳理，将工作流程进行标准化。企业在没有将业务理顺之前就上马信息系统，往往导致达不到既定目标，从而把责任怪罪到信息系统上。

3.1.3 计划不切实际

由于诸多原因，信息系统开发项目一般周期都比较短。大多数企业要求签订合同两～三个月以内甚至更短的周期内交付系统。乙方面对一个完不成的计划，而又不愿意失去商机，就只能在各个方面进行“偷工减料”，项目失败的概率也大幅提高。

3.2 情景因素

情景因素主要是公司高层的支持以及各种面向项目的政策支持，是信息系统开发成功的助推剂。

表1：信息系统项目失败分析模型

表 2：基于Scrum 的解决方案

3.2.1 高层支持

信息系统从立项到开发实施再到后期运用，都离不开高层支持，因为高层的支持，代表了公司意志，员工必须遵照执行。同时高层具有较大的权力，比如人事评价、资源调度等，这些权力影响着员工个人的利益。因此高层出席项目的里程碑会议、在各种场合对项目鼓励等，影响着所有项目干系人，能加强他们对项目的认同感和责任感，对项目的成功起到关键作用[3]。

3.2.2 促进因素

在导入信息系统时，适当的促进因素有助于提升用户的参与。比如给予参与项目的员工一些表扬甚至是物质性奖励。

3.3 人员因素

信息系统的开发和运用都离不开人的参与。经常会有一种误解：信息系统的开发阶段是乙方开发团队的事，上线运营后是甲方运营团队的事。但是一个真正成功的信息系统，无论是开发阶段还是使用阶段，都离不开甲乙双方开发和运营团队的共同参与。

3.3.1 客户参与度

客户的积极参与是项目成功的关键[4]。无论是业务调研阶段还是开发过程中的需求确认，都需要典型客户代表以及具有最终决定权的关键干系人参与。客户参与度不高的话，往往会导致问题在项目后期或者交付后才被发现，纠错代价极高。

3.3.2 开发团队技能

毋庸置疑，开发团队的技能，无论是项目管理水平还是技术能力，都直接影响项目的进度、质量和成本。好的项目经理对外积极主动与客户沟通、把握项目范围，对内制定计划、协调资源并按照计划推进。而项目组的编码人员的能力也至关重要，好的程序员不仅效率比普通人员高，而且代码质量更好。

3.4 商务因素

商务因素有很多，这里主要指信息系统开发实施的价格和边界两个因素。

3.4.1 合理价格

在信息系统建设过程中，如果乙方的收益不能保证合理的利润，又没有其他值得期待的收益（比如进入某个行业、树立标杆客户等），则很容易导致乙方“偷工减料”。价格之所以出现不合理的情况，可能是恶意竞标、层层转包等原因导致的。

3.4.2 边界明确

信息系统作为软件项目，往往很难对开发范围进行非常精准的界定。实际操作中，往往是靠甲乙双方不断交流逐步明确边界，交流的过程是一个相互博弈的过程。如果甲乙双方不能进行良好的沟通，将会导致需求蔓延，最终导致项目失败。

4 避免信息系统项目失败的对策

根据前文的原因分析，可以发现大部分的问题都通过甲乙双方进行深入交流、共同明确需求和计划并不断迭代以降低风险进行解决。而敏捷开发模式本身具备的特征，正好可以作为解决信息系统项目失败的一种解决方案。

4.1 敏捷软件开发

敏捷软件开发方法出现于上世纪60年代，90年代开始，一些开发方法如Rapid Application Development（RAD）、Scrum、Extreme Programming (XP)等越来越受到人们的关注，特别是Scrum 和XP 的实践者甚多。这些方法论强调了四个方面：

（1）开发团队和业务干系人之间的密切合作；

（2）商业价值频繁交付；

（3）紧密合作的自组织团队；

（4）代码匠艺、验证和交付代码的巧妙方法[5]。

2001年2月，17 位软件行业领军人物聚在一起，共同发布了敏捷软件开发宣言和十二条原则。基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称就是敏捷软件开发模式[5]。其中“客户合作高于合同谈判、响应变化高于遵循计划[6]”的思想对解决信息系统的失败有很好的启迪。

Scrum 是敏捷开发方法的一种实践，是开发和持续支持复杂产品一个框架。在这个框架中，整个开发过程由若干个长度为一到四周的Sprint 组成，每个Sprint 优先开发对客户具有较高价值的需求[7]。

4.2 Scrum解决信息系统失败的方案

根据Scrum 开发框架的特征，结合信息系统项目失败的原因，制定面向信息系统开发的解决方案，如表2所示。

根据Scrum 的角色、工件和事件分别对甲方和乙方的相关干系人进行定义。

（1）甲方工作内容：甲方派出人员作为产品负责人（Product Owner，简称：PO），收集需求，决定开发内容，即产品列表；同时决定每个Sprint 开发列表，并参与每个Sprint 的计划会议和评审会议。根据敏捷宣言中“业务人员和开发人员必须相互合作，项目中的每一天都不例外”的规定，甲方的PO 作为专职人员，随时保持与项目开发人员的沟通。另外，PO 必须具有一定的影响力，能够从业务人员处收集到真实的需求，并且能够在重要的里程碑节点，邀请高层人员试用并对系统进行评价。

（2）乙方人员担任ScrumMaster（简称：SM）和开发团队的角色，主要负责各产品列表的实现工作，提交可见的成果供甲方验证。乙方人员必须参与计划会议，讨论Sprint 的工作内容；参加每日站会，汇报进度和工作成果，及时解决每日问题；参加评审会议，了解客户的反馈；参加回顾会议，不断进行反省和提高。

通过基于Scrum 开发框架的解决方案，可以解决信息系统失败原因中的“需求明确性、计划合理性、高层支持、客户参与度、边界界定”等导致的问题。由于双方统一了战线，形成了一个有机整体，因此对需求、计划的理解和制定将更加趋向一致。对于“准备充分度”原因导致的项目失败，通过甲方人员担任PO 角色可以得到很大程度的改善。由于每两周就发布一个版本，因此可以将版本及时提供给重要干系人试用，及时了解他们的想法，通过持续吸引重要干系人的关注，从而解决“高层支持、促进因素”的问题。

另外，对于需求尚不明确的信息系统，也可以通过Scrum 开发框架，采用POC（Proof of Concept）的思想进行验证，当发现结果不理想时可以及时终止项目，及时止损。

关于“价格合理”的问题，Scrum 框架虽然无法直接解决，但是由于双方人员是一个有机的整体，双方交流频繁，信任程度将得到大幅提高，因此对于合同价格的恶意竞争将大幅减少，甚至只是签订框架性合同，然后根据每个Sprint 的工作量进行结算。