时间: 2024-10-25 19:43:55 | 作者: 总包项目
在开展数字化服务的过程中,畅享网深感于软件项目成功因素之广,主体之多,复杂度之高,路径之长。按照业务需求和建设目标的达成度来衡量成功与否的话,软件项目的顺利成功慢慢的变成了偶然,过程曲折、委曲求全、局部失败甚至烂尾工程成为必然。对大型组织来说,总包管理的不专业现象,都会存在,阻碍软件工程的成功。
本文所依据的事实来自所采集的22个总包分包负面案例,期望通过案例分析引发业内人士共鸣,引起管理者重视。所做问题分析,力求贴近现实,所提供的对策分析,力争可当作初始方案,供管理者进一步论证,以启动数字化项目管理变革。
软件工程涉及数字化管理部门、业务需求部门、预算管理部门等业主部门,也涉及承建商、专业分包商、设计监理测评机构等供应商,业主管理模式主要有自主管理、总包管理、混合模式。在政府信息化领域,总包模式和混合模式慢慢的变成了政府部门开展数字化工程的主要模式,总包的角色一般由国有企业及有一定的影响力的别的类型企业承担,以期更好地平衡社会价值和经济价值。在市场化程度更高的民营和外资企业,既有业主方主动选择的总包行为,也有因中标商私下分包所造成的总包行为。
在工程领域,总包模式有必然性,主要是因为精细化分工需要由不同分包商协作完成。分包商的遴选和管理,一般由总包商进行,业主仅关注总包商与自己之间的合约,分包商行为可能会影响项目的结果,业主追究总包商的责任,因为总包商对分包商是有管理义务的。
政府、医疗教育等行业软件工程的实施,包括了交易的三种类型:买卖的交易,即平等的组织之间的交换关系;管理的交易,即上下级之间的交换关系;限额的交易,主要指政府与组织的关系。软件工程总包模式的选择,既有行业交易特点的因素,也有软件专业特点的因素,既有业主主动选择,也有业主被动选择。
1、行业交易特点。数字化项目成功因素广、主体多、复杂度高、周期长,业主采用总包模式,可以较好地将职责由总包商承担,更好地发挥专业服务商的能力,在某一种意义上也转移风险和责任。
2、软件专业特点。数字化项目中的硬件集成部分,多为标准化产品,沟通成本低,总包管理模式运行良好。软件开发涉及业务和技术领域广,专业性强,新概念、新模式多,对人的依赖度高。
3、业主主动选择。政府部门、事业单位及一级国企单位因为编制有限、经营事物的规模广,在实施数字化工程时,采用总包或代建模式,代表业主方开展项目管理。代建模式决策过程很复杂,总包模式具有决策灵活和实施便利的特点,更容易为业主方选择。
4、业主被动选择。业主方在组织招标时,所要求的不是总包项目,而是单体建设项目,不允许分包。而中标商投标行为不规范,私自借壳、串通投标、低价竞争等,在中标后,自己并不实际交付,而是由分包商负责主要交付。业主方往往在项目启动一段时间后才觉察到分包行为,此时项目分包模式慢慢的变成了事实。
总包模式为业主方带来了风险转移但不是风险消解。对政府和事业单位来说,上下级有行政约束,比如绩效评价、人事任免等,但对企业包括国企也没有行政约束,人能离职而不受制约。对官僚主义风比较普遍的大公司来说,经济约束效果也有限。
本文搜集到因总分包而失败的案例,来自政府机构、教育单位、国有企业、非公有制企业以及外资企业等。总包模式的负面后果类型比较多,本次研究搜集的案例样本为22个,定量统计学意义比较小,分析时更多采用定性分析法和案例分析法。
在收集到的负面案例中,站在总包商和分包商的角度,总包模式所暴露出的问题以经济方面为多,主要有以下四个方面。
1、分包商回款难。总包商在验收并收到客户款项后,因自身资金紧张,无法按合同约定支付分包商款项。或者,总包商因与业主方验收结算、财务政策、内部矛盾等问题,导致给分包商的付款节点推迟。软件开发项目普遍存在项目内容变更,由此产生的合同金额变更往往导致承包商收款周期延长,年度项目成为跨年甚至跨多年的项目。在收集到的负面案例中,此情况占比最多。
2、合同内容变更多。在业务需求内容减少时,总包商与业主单位洽谈商务变更,带来结算金额缩减。在业务需求溢出时,总包商与业主单位洽谈商务变更,可能带来结算金额增加。业务需求变更,打破了总包方和分包方的合同约定内容,带来了双方工作推进的摩擦。在收集到的负面案例中,此情况占比为第二位。
3、分包金额共识难。业主和总包商的合同改变信息,对分包商是难以做到及时公开的。总包商和分包商对结算金额及周期较难达成一致,甚至不欢而散。总包商与业主方的合作,经常是多合同合作,而分包商与总包商可能是一次性合作。总包商可能损害分包商利益而讨好业主。从工程管理的角度讲,业主是不用去管理分包商的,总包商与分包商之间应该有分包合同约束。但在真实的操作中,软件行业总包商经常不是专业的总包商,总包管理上的水准比较低。
4、项目资源协调难。软件工程的责任后果由总包商负责,质量和进度良好,总包商得名、得利;质量和进度差,总包商损失口碑和金钱。分包商服务的品质优劣,对自身利益影响不大,因此分包商多把交差、过关、验收、收款作为上限目标,派出中等水平服务人员提供服务,不会派出能力强的服务人员。
总包商和分包商的上述矛盾是比较尖锐的,很难调和,在业主方所给的招标限额及总包商的中标金额有限的情况下,矛盾会更加激化,往往导致业主方需要承担如下风险:
1、质量低。经济利益和关系矛盾,使得分包商不愿意投入高水平人员,导致数字化项目的质量打折扣,达不到预想的效果。因推诿扯皮、各有盘算、方案反复、干干停停,交涉时间多于干活时间,使得工期难保障。
2、运营差。责任、荣誉、产权与付出和收益不匹配,在上线后的运维运营、迭代升级阶段,分包商因商务原因不愿意提供高品质服务,使得运维运营工作难以为继。业主方成为负面结果的承担者。
3、追责难。涉及部门多、服务商多,在服务商评价、立项预算、安全合规等方面,由多方协同决策,导致最终难以界定问题责任。
1、需求的不确定性。数字化项目中的软件开发部分,因为政策和业务变化由上到下,业务和管理存在不确定性,领导岗位变化带来思路变换,业务需求和方案设计处于动态调整状态,软件作品非标准化属性显著。加上多部门民主决策和分权协作,使得数字化项目有关人员边想边干,边干边想,成为政府、医疗教育等行业的软件工程常态。
2、立项的不确定性。业主方业务和技术部门,因为上级要求和业务需求,在项目立项过程中及项目立项前,即开始引入供应商参与前期工作、设计工作及开发工作。供应商因业务部门或技术部门的工作人员要求,以及自身拓展业务、生米煮成熟饭的利益冲动,先开展设计和开发工作,再走立项和商务流程。政策、人事、预算等具有不确定性,往往未能最终立项,总包商没办法拿到合同和费用,导致分包商的投入没有回报。
3、关系的不确定性。在传统工程领域,业主方、总包方、分包方的责权利是清晰的,各方的工程管理上的水准很高。在软件工程领域,总包及分包工程管理处于低水平状态。业主方对总包方寄予的期望经常比较大,责任转移。总包方对自己的责任、权力及利益的认识水平层次不齐,对分包商的责权利也没有清醒的认识,在合同签署、合同条款、日常沟通上,都会存在错位、越位和缺位的现象。在发生冲突时,经常束手无策。
需求方、建设方、总包方、分包方、第三方的本位主义,决定了软件工程的沟通成本高,协作难,而各方目前的综合水平难以胜任这些挑战,使得总包模式和混合模式难以达到项目的预期。
1、业主方水平。业主方经常分需求部门和技术部门。技术部门因为人员数量少、心态不积极,对总包商疏于管理,或心有余力不足。业务部门因为对IT生态圈运行规则不了解,不熟悉借壳、低价中标等风险点。
2、总包方水平。总包方在签约前,因利益驱动会蔓延需求、增大合同额。在签约后实施时,会推诿塞责,减少上线工作量。业主方因为预算管理、业绩考核原因,总会验收项目并付款。总包方经常为大公司,经营事物的规模广,在软件开发领域不擅长,软件开发的项目管理和经验弱于分包商。角色和能力错位,加剧沟通摩擦。
3、分包商水平。分包商一般为中小企业,所派出服务的人员也为该公司一般人员,因此行业认知深度、专业交付能力、理解沟通水平都偏低。总包类项目的专业复杂性,加剧了分包商与总包商能力的错位和矛盾。
4、监理方水平。软件项目要求监理工程师要不仅要懂监理规范和项目管理规范,而且要对软件开发规律、软件技术、普遍的问题及应对措施有较深的了解,才能为软件开发项目经理及工程师提供合理化建议和要求。这种水平的监理工程师是比较少的。
软件工程的业务特点,是体制、文化和业务使然。利益相关者行为,是人性使然。这是没法直接改变的。发展对策主要是在机制和制度方面。通过机制和制度的创新设计,大幅度的降低组织内外的交易费用,提高软件工程外包的效果效率。
应该通过多元主体的制度设计,提高软件工程外包管理的专业化水平,业主、总包商和分包商之间的责任、权利和利益应明确划分,确保各方在项目中的角色和期望一致,提高项目管理的效率和质量,减少风险,保护业主方的利益,避免因管理不善而导致的经济损失和信誉损害。
(1) 招标管理。软件设计和开发常常要高度的创造性和协作性,不宜分包。如果必须分包,应确保分包商具备相应的资质和能力,并且总包商应对最终成果负责。在招标和合同文件中,应明确规定后期分包、变更的管理流程和约束条件,确保所有参与方都明白自己的责任和义务。
(2) 分包管理。主要工作应由总包商亲自完成,分包必须得到业主方的认可。业主方应对中标商未经同意的分包行为保持警惕,评估风险,并要求中标商提供详细的分包计划和资质证明。业主方应要求总包商与分包商之间的合同规范化,需要详细界定分包的功能需求和技术方面的要求,约定变更规范、费用调整机制、争议解决机制等,明确双方的权利和义务。分包额应有明确的比例限制,避免二次分包,确保分包工作的质量。
(3) 业主方角色。业主方应积极履行监督和管理职责,对于总包和分包之间的矛盾应及时调解,避免因忽视而导致项目失败。项目中应建立严格的监督和审计机制,确保所有流程透明公正,减少腐败行为的发生。变更是软件工程中的常见情况,业主方应建立一套有效的变更管理流程,包括变更的申请、审批、实施和结算等环节。
软件系统分稳态应用和敏态应用。稳态应用及需求在一定时期内能稳定的敏态应用,采用固定价合同,应做好可行性研究和需求分析,减少项目变更。对于业务部门急需但需求又难以稳定的敏态应用,设定评估规则,采用按成果结算模式,由专业评估机构评估结算金额。也能够使用服务目录,明码实价,使得结算系统化、标准化、规范化,在上线后评估工作成果数量,按实际成果和成效付费。标准化的费用结构和计价方式,使得立项速度加快,立项质量提高,总包方和分包方的工作成果及其费用透明化。
业主方建立强有力的、由业主方管理的应用支撑平台,也可以叫数字底座、PaaS平台、技术中台、公共能力等,提供公共的开发和服务能力,如用户和权限管理、低代码开发、门户管理、数据处理、文档处理、开放能力、运营管理等,并出台技术制度规范,实现应用模块化和松耦合。业主方引入多家服务商,在一个平台上提供开发服务,互相间存在竞争关系,减少对单一供应商的依赖。以技术平台的标准化、规范化和一体化,服务的低成本、快速响应和多团队支撑,降低上线前对开发商的技术依赖,也使得运维运营阶段不再受制于开发商。返回搜狐,查看更加多