定制化软件采购中，如何避免验收闹

如何避免验收闹呢？

下面笔者就带大家来探讨一下

近期小明经历了一场“验收闹”，服务商务找到商务部门催款道：按照合同约定的付款节点，我司已经完成了上线，请尽快发起上线款的申请。

采购部门根据服务商的反馈，发邮件至业务部门确认是否验收，结果被驳回。使用单位反问道：目前，服务商提供的软件模块，没有一个能够正常使用的，这种能叫上线？

最终，经过采购部门的协调，服务商与使用部门再次进行沟通后，服务商根据使用部门的反馈的不足进行了修正，使用部门也将范围外的需求拆出来作为项目二期的内容；最终，系统顺利完成上线验收。

01、产生验收闹的原因

小明从中总结了产生验收闹的几点原因：

1.服务商讲标人经验丰富，但是对于需求的复杂度理解不足，导致落地的业务顾问对需求的把控明显很弱。

笔者曾经跟一位资深的系统服务商聊过，问他：现在软件实施好做吗？他回答：比几年前难做多了。笔者接着问道：为什么呢？服务商答道：之前，标准的软件直接推给客户，现在国内的企业管理水平上来了，定制化的要求越来越高，这意味着对于业务顾问和实施顾问的要求比较高。

那么如何避免此类验收闹呢？下面笔者就带大家来探讨一下。

02、供应商的筛选

第一点，引用乔治奥威尔的话：“只有披露了一些丢脸的事情的自传才值得信任”。那么，在选服务商的时候，首先，让服务商提供成功落地的项目经验；其次，也需要让对方拿出一个失败的案例或者一些复杂项目的经验。这里要注意，一定是同行业的项目经历。

本案例中，小明回忆了一下，讲标的现场，讲标人热情洋溢的讲了系统的逻辑，也完美的回答了使用部门的问题；但是，并没有给出一个同类项目的落地案例。同时，小明跟IT部门的项目对接人也做了了解，反馈：服务商对于需求的把控能力比较弱。

举个例子：服务商提供的标准化的模块，遇到与业务不符合的情况，需要与使用部门共同探讨后给出解决方案或者放入二期；但是该服务商的状态是：对于使用部门提出的需求，不断承诺，直到发现无法完成。

第二点，公司的规模和体量的要求。规模太大的公司，虽然有丰富的资源，但是未必愿意投入资源在客户身上。规模过小的公司，内部资源有限，遇到问题的时候，难免会耗费时间去找合适的资源，进而会拖延项目的进度，浪费客户的时间和资源。所以，采购需要用供应商认知模型分析一下，在供应商心中地位，选择最合适的服务商。

在本案例中，IT部门就指出：服务商在项目开始时，派来一名业务顾问，进行业务调研和梳理，但是一个月后，发现业务场景复杂，不能拿出良好的解决方案，最终无果；服务商又花费了两周的时间找到新的业务咨询顾问，导致本该在一个月就应该完成的调研和梳理工作，比原计划推迟了一个月。

第三点，采购方式。此类项目的采购，建议使用招投标的方式或者至少是综合评分，这个避免由于项目过程管控不好，导致项目出问题后，全盘甩锅给服务商，最终让采购背锅。

本案例中，在项目开始的初期，双方在遇到冲突时，经常会听到使用部门的一句话：谁选的供应商，一定要到审计部门投诉。小明都很淡定，首先，入围的供应商清单，由使用和IT部门共同参与选定；其次，中标单位是招投标小组最终的评分结论。

03、合同中的要点

首先，sow的书写。这个由使用部门和IT部门共同完成后，同步给服务商，最终达成一致后，作为合同附件。

第二，服务商的项目成员必须经过IT部门的面试后，人员名单和服务的时长固定在合同中。

第三，付款条件。这个由采购和IT部门根据项目的实施里程碑的节点，共同商讨后由采购输出，与服务商达成一致，固定在合同中；一般项目会分成六次付款：预付，蓝图，测试，上线，上线三个月以及六个月稳定期。

第四，实施中，每个节点需要输出的文件，需要在合同中做说明，避免验收时无依据或者缺失导致无法验收。

最后，是系统维保的约定。通常情况下，行业内会有两种约定：一种是合同金额的15%，另外一种是约定了人工的单价即不高于原合同单价，最终按照实际的人天进行结算。通常情况下，建议采用第二种，成本可控并且更加灵活。

04、总结

面对IT定制化平台项目的采购，从需求提出，到入围厂商的确认，会经历漫长的周期，非常耗费时间资源；到了实际采购阶段，就是那句：留给采购的时间不多了，所以采购经常会背着采购不及时的骂名。

快马加鞭的筛选，好不容易选定了合适的服务商，本以为皆大欢喜；实际采购不参与实施的过程，但是当项目进展不顺利的时候，采购又会被拉入扯皮和内耗的困境。

所以，采购一定要眼明手快，无论在需求确认或者供应商选择阶段，还是合同的签订阶段，都要保持客观公正的同时，留意指出缺陷和疏失。这样才能最大限度的规避风险，保证项目的顺利交付和上线。