软件工程总包模式的问题深度解析

在开展数字化服务的过程中，畅享网深感于软件项目成功因素之广，主体之多，复杂度之高，路径之长。按照业务需求和建设目标的达成度来衡量成功与否的话，软件项目的顺利成功已经成为偶然，过程曲折、委曲求全、局部失败甚至烂尾工程成为必然。对大型组织来说，总包管理的不专业现象，普遍存在，阻碍软件工程的成功。
本文所依据的事实来自所采集的22个总包分包负面案例，期望通过案例分析引发业内人士共鸣，引起管理者重视。所做问题分析，力求贴近现实，所提供的对策分析，力争可以作为初始方案，供管理者进一步论证，以启动数字化项目管理变革。

采用应用支撑平台模式，做强自主能力，不再受制于服务商

《国有企业集团信息化规划和设计研究》连载3-3

政务信息化绩效评价工作方法研究

软件工程涉及数字化管理部门、业务需求部门、预算管理部门等业主部门，也涉及承建商、专业分包商、设计监理测评机构等供应商，业主管理模式主要有自主管理、总包管理、混合模式。在政府信息化领域，总包模式和混合模式已经成为政府部门开展数字化工程的主要模式，总包的角色一般由国有企业及有影响力的其他类型企业承担，以期更好地平衡社会价值和经济价值。在市场化程度更高的民营和外资企业，既有业主方主动选择的总包行为，也有因中标商私下分包所造成的总包行为。

一、总包模式的选择

在工程领域，总包模式有必然性，主要是因为精细化分工需要由不同分包商协作完成。分包商的遴选和管理，一般由总包商进行，业主仅关注总包商与自己之间的合约，分包商行为可能会影响项目的结果，业主追究总包商的责任，因为总包商对分包商是有管理义务的。

政府、医疗教育等行业软件工程的实施，包括了交易的三种类型：买卖的交易，即平等的组织之间的交换关系；管理的交易，即上下级之间的交换关系；限额的交易，主要指政府与组织的关系。软件工程总包模式的选择，既有行业交易特点的因素，也有软件专业特点的因素，既有业主主动选择，也有业主被动选择。

1、行业交易特点。数字化项目成功因素广、主体多、复杂度高、周期长，业主采用总包模式，可以较好地将职责由总包商承担，更好地发挥专业服务商的能力，在某种意义上也转移风险和责任。

2、软件专业特点。数字化项目中的硬件集成部分，多为标准化产品，沟通成本低，总包管理模式运行良好。软件开发涉及业务和技术领域广，专业性强，新概念、新模式多，对人的依赖度高。

3、业主主动选择。政府部门、事业单位及一级国企单位因为编制有限、业务范围广，在实施数字化工程时，采用总包或代建模式，代表业主方开展项目管理。代建模式决策过程比较复杂，总包模式具有决策灵活和实施便利的特点，更容易为业主方选择。

4、业主被动选择。业主方在组织招标时，所要求的不是总包项目，而是单体建设项目，不允许分包。而中标商投标行为不规范，私自借壳、串通投标、低价竞争等，在中标后，自己并不实际交付，而是由分包商负责主要交付。业主方往往在项目启动一段时间后才觉察到分包行为，此时项目分包模式已经成为事实。

二、总包模式的负面后果分析

总包模式为业主方带来了风险转移但不是风险消解。对政府和事业单位来说，上下级有行政约束，比如绩效评价、人事任免等，但对企业包括国企也没有行政约束，人员可以离职而不受制约。对官僚主义风比较普遍的大公司来说，经济约束效果也有限。

本文搜集到因总分包而失败的案例，来自政府机构、教育单位、国有企业、民营企业以及外资企业等。总包模式的负面后果类型比较多，本次研究搜集的案例样本为22个，定量统计学意义比较小，分析时更多采用定性分析法和案例分析法。

在收集到的负面案例中，站在总包商和分包商的角度，总包模式所暴露出的问题以经济方面为多，主要有以下四个方面。

1、分包商回款难。总包商在验收并收到客户款项后，因自身资金紧张，无法按合同约定支付分包商款项。或者，总包商因与业主方验收结算、财务政策、内部矛盾等问题，导致给分包商的付款节点推迟。软件开发项目普遍存在项目内容变更，由此产生的合同金额变更往往导致承包商收款周期延长，年度项目成为跨年甚至跨多年的项目。在收集到的负面案例中，此情况占比最多。

2、合同内容变更多。在业务需求内容减少时，总包商与业主单位洽谈商务变更，带来结算金额缩减。在业务需求溢出时，总包商与业主单位洽谈商务变更，可能带来结算金额增加。业务需求变更，打破了总包方和分包方的合同约定内容，带来了双方工作推进的摩擦。在收集到的负面案例中，此情况占比为第二位。

3、分包金额共识难。业主和总包商的合同变更信息，对分包商是难以做到及时公开的。总包商和分包商对结算金额及周期较难达成一致，甚至不欢而散。总包商与业主方的合作，经常是多合同合作，而分包商与总包商可能是一次性合作。总包商可能损害分包商利益而讨好业主。从工程管理的角度讲，业主是不用去管理分包商的，总包商与分包商之间应该有分包合同约束。但在实际操作中，软件行业总包商经常不是专业的总包商，总包管理水平比较低。

4、项目资源协调难。软件工程的责任后果由总包商负责，质量和进度良好，总包商得名、得利；质量和进度差，总包商损失口碑和金钱。分包商服务质量优劣，对自身利益影响不大，因此分包商多把交差、过关、验收、收款作为上限目标，派出中等水平服务人员提供服务，不会派出能力强的服务人员。

总包商和分包商的上述矛盾是比较尖锐的，很难调和，在业主方所给的招标限额及总包商的中标金额有限的情况下，矛盾会更加激化，往往导致业主方需要承担如下风险：

1、质量低。经济利益和关系矛盾，使得分包商不愿意投入高水平人员，导致数字化项目的质量打折扣，达不到预想的效果。因推诿扯皮、各有盘算、方案反复、干干停停，交涉时间多于干活时间，使得工期难保障。

2、运营差。责任、荣誉、产权与付出和收益不匹配，在上线后的运维运营、迭代升级阶段，分包商因商务原因不愿意提供高品质服务，使得运维运营工作难以为继。业主方成为负面结果的承担者。

3、追责难。涉及部门多、服务商多，在服务商评价、立项预算、安全合规等方面，由多方协同决策，导致最终难以界定问题责任。

三、总包模式问题分析与对策研究

（一）业务特点分析

软件工程的总包模式所导致的问题，来自于其业务和管理特点，主要是：

1、需求的不确定性。数字化项目中的软件开发部分，因为政策和业务变化由上到下，业务和管理存在不确定性，领导岗位变化带来思路变换，业务需求和方案设计处于动态调整状态，软件作品非标准化属性显著。加上多部门民主决策和分权协作，使得数字化项目相关人员边想边干，边干边想，成为政府、医疗教育等行业的软件工程常态。

2、立项的不确定性。业主方业务和技术部门，因为上级要求和业务需求，在项目立项过程中及项目立项前，即开始引入供应商参与前期工作、设计工作及开发工作。供应商因业务部门或技术部门的工作人员要求，以及自身拓展业务、生米煮成熟饭的利益冲动，先开展设计和开发工作，再走立项和商务流程。政策、人事、预算等具有不确定性，往往未能最终立项，总包商无法拿到合同和费用，导致分包商的投入没有回报。

3、关系的不确定性。在传统工程领域，业主方、总包方、分包方的责权利是清晰的，各方的工程管理水平很高。在软件工程领域，总包及分包工程管理处于低水平状态。业主方对总包方寄予的期望经常比较大，责任转移。总包方对自己的责任、权力及利益的认识水平层次不齐，对分包商的责权利也没有清醒的认识，在合同签署、合同条款、日常沟通上，普遍存在错位、越位和缺位的现象。在发生冲突时，经常束手无策。

（二）利益相关者分析

需求方、建设方、总包方、分包方、第三方的本位主义，决定了软件工程的沟通成本高，协作难，而各方目前的综合水平难以胜任这些挑战，使得总包模式和混合模式难以达到项目的预期。

1、业主方水平。业主方经常分需求部门和技术部门。技术部门因为人员数量少、心态不积极，对总包商疏于管理，或心有余力不足。业务部门因为对IT生态圈运行规则不了解，不熟悉借壳、低价中标等风险点。

2、总包方水平。总包方在签约前，因利益驱动会蔓延需求、增大合同额。在签约后实施时，会推诿塞责，减少上线工作量。业主方因为预算管理、业绩考核原因，总会验收项目并付款。总包方经常为大公司，业务范围广，在软件开发领域不擅长，软件开发的项目管理和经验弱于分包商。角色和能力错位，加剧沟通摩擦。

3、分包商水平。分包商一般为中小企业，所派出服务的人员也为该公司一般人员，因此行业认知深度、专业交付能力、理解沟通水平都偏低。总包类项目的专业复杂性，加剧了分包商与总包商能力的错位和矛盾。

4、监理方水平。软件项目要求监理工程师要不仅要懂监理规范和项目管理规范，而且要对软件开发规律、软件技术、常见问题及应对措施有较深的了解，才能为软件开发项目经理及工程师提供合理化建议和要求。这种水平的监理工程师是比较少的。

（三）发展对策分析

软件工程的业务特点，是体制、文化和业务使然。利益相关者行为，是人性使然。这是没法直接改变的。发展对策主要是在机制和制度方面。通过机制和制度的创新设计，大大降低组织内外的交易费用，提高软件工程外包的效果效率。

1、外包管理专业化

应该通过多元主体的制度设计，提高软件工程外包管理的专业化水平，业主、总包商和分包商之间的责任、权利和利益应明确划分，确保各方在项目中的角色和期望一致，提高项目管理的效率和质量，减少风险，保护业主方的利益，避免因管理不善而导致的经济损失和信誉损害。

(1) 招标管理。软件设计和开发通常需要高度的创造性和协作性，不宜分包。如果必须分包，应确保分包商具备相应的资质和能力，并且总包商应对最终成果负责。在招标和合同文件中，应明确规定后期分包、变更的管理流程和约束条件，确保所有参与方都清楚自己的责任和义务。

(2) 分包管理。主要工作应由总包商亲自完成，分包必须得到业主方的认可。业主方应对中标商未经同意的分包行为保持警惕，评估风险，并要求中标商提供详细的分包计划和资质证明。业主方应要求总包商与分包商之间的合同规范化，需要详细界定分包的功能需求和技术要求，约定变更规范、费用调整机制、争议解决机制等，明确双方的权利和义务。分包额应有明确的比例限制，避免二次分包，确保分包工作的质量。

(3) 业主方角色。业主方应积极履行监督和管理职责，对于总包和分包之间的矛盾应及时调解，避免因忽视而导致项目失败。项目中应建立严格的监督和审计机制，确保所有流程透明公正，减少腐败行为的发生。变更是软件工程中的常见情况，业主方应建立一套有效的变更管理流程，包括变更的申请、审批、实施和结算等环节。

2、费用结算标准化

软件系统分稳态应用和敏态应用。稳态应用及需求在一定时期内能稳定的敏态应用，采用固定价合同，应做好可行性研究和需求分析，减少项目变更。对于业务部门急需但需求又难以稳定的敏态应用，设定评估规则，采用按成果结算模式，由专业评估机构评估结算金额。也可以采用服务目录，明码实价，使得结算系统化、标准化、规范化，在上线后评估工作成果数量，按实际成果和成效付费。标准化的费用结构和计价方式，使得立项速度加快，立项质量提高，总包方和分包方的工作成果及其费用透明化。

3、服务力量多元化

业主方建立强有力的、由业主方管理的应用支撑平台，也可以叫数字底座、PaaS平台、技术中台、公共能力等，提供公共的开发和服务能力，如用户和权限管理、低代码开发、门户管理、数据处理、文档处理、开放能力、运营管理等，并出台技术制度规范，实现应用模块化和松耦合。业主方引入多家服务商，在一个平台上提供开发服务，互相间存在竞争关系，减少对单一供应商的依赖。以技术平台的标准化、规范化和一体化，服务的低成本、快速响应和多团队支撑，降低上线前对开发商的技术依赖，也使得运维运营阶段不再受制于开发商。