实施费二开费接口费，哪些该写进合同

一、会议桌上，先把这些费一项项摆开

会议室的投影停在费用清单那一页，采购负责人逐行往下念：实施、二次开发、接口、培训、年度服务。念到一半，业务负责人抬手打断：这一项难道不该包含在系统里吗？厂商代表笑笑：包含，但要看做到什么深度。会议桌上的气氛，立刻微妙起来。

• ● 实施费：把现有流程搬进系统、做基础配置的人工开销。
• ● 二开费：标准功能覆盖不了的部分，需要另行开发。
• ● 接口费：跟财务、仓储、商城等系统打通的开销。
• ● 培训与服务：教会大家用，出了问题有人管。
• ● 越早摆开越主动，拖到签约之后，主动权就换边了。

类似的场面在采购项目里反复上演。倒不是哪一方不诚信，而是这些项目的边界天然模糊：同样是配置流程，配到什么深度算包含、配到什么深度算新增，不摆到桌面上，谁也说不清。

这份清单背后其实是一个更根本的问题：买系统到底买的是什么。标准功能是厂商做好的部分，实施是把你的业务装进去的部分，二开和接口是把系统跟你的世界连起来的部分。每一部分都要花人力，有人力就有开销。这不是套路，是行业的本来面目。

• ● 与其争论该不该收，不如逐项摆开。把每一项的边界一次谈透。
• ● 摆得越早越好，落到签约之后，筹码就换了一边。

谈判桌上的规律很朴素：纸面之前什么都能谈，纸面之后什么都难谈。实话讲，费用清单这一页，值得坐下来慢慢过。

二、边界不清，追加就没有尽头

边界模糊的项目，追加需求就会像潮水一样，一波接一波。每一波都理由充分。

• ● 深度没定义：配置流程配到多细算包含、多细算另收，没说清就是伏笔。
• ● 范围没锁定：接口做几个、给谁用、调多少，都可能变成追加的理由。
• ● 验收没标准：做完算不算好，双方理解不一，尾款就悬在那里。
• ● 人员没约束：中途换人、换方案，前面做的部分推倒重来，开销跟着翻番。
• ● 沟通没留痕：口头答应过的范围，事后谁都不认。

有一家做家居用品的企业深有体会。签约时只谈了实施的总包价，上线过程中业务部门不断提出新想法，厂商来者不拒、逐项报价，等项目收尾一算，追加的部分快赶上签约时的实施了。追责追不出结果，每一项追加都是业务自己提的。

问题出在起点：签约时没有定义边界，实施过程中就没有任何东西能拦住需求的膨胀。业务提想法没有错，错的是没有一堵墙告诉所有人，墙里是约定好的，墙外是另算的。

墙这个比喻值得多说一句。墙不是拒绝变化，而是区分性质的一道线：墙里的需求按约定做，墙外的需求走另一套评估流程。有了这道线，业务提需求时心里有数，厂商报价时也有依据。双方反而都轻松。

• ● 把包含的范围画成一堵墙，墙外的逐项评估、逐项确认。
• ● 每项追加都要有业务负责人签字。别让口头需求直接变成账单。

三、哪些必须落纸，哪些可以放开谈

不是所有事情都要写死，写死一切既不现实也没必要。关键是分清哪些必须落纸，哪些可以放开。

• ● 必须落纸：实施的范围与深度、二开的交付物与验收标准、接口的对象与数量。
• ● 可以放开：上线之后的新需求，约定按工时估算、按节点确认即可，不必预先锁死。
• ● 关键一条：每项开销的触发条件写清楚，什么情况算包含、什么情况算新增。

图1：里程碑排清楚，费用节点才对得上

必须落纸的，是那些金额大、边界模糊、事后说不清的项目。实施深度是重灾区，建议把典型场景写进附件：入库一个客户要配哪些字段、走哪条流程，做到什么程度算完成。场景写得越具体，各自解读的空间就越小。

可以放开的，是那些现在还想象不到的需求。硬要预先锁死，要么锁不住，要么锁出一个天价。放开但有规矩：工时怎么估、谁确认、超了怎么办，这套机制谈好比锁死清单更管用。

写场景清单时有个小技巧：挑那些最常发生、最典型的业务，别挑边角案例。说穿了，清单不求覆盖一切，求的是给双方一个校准理解的机会，看过同一批场景之后。大家对包含二字的认知会接近很多。

• ● 落纸的求具体，放开的求机制，两条腿走路。
• ● 附件里的场景清单，让真正干活的人参与写。别让文案代劳。

四、节点和验收，要跟开销对齐

费用谈清之后，还要解决一个何时付、凭什么付的问题。节奏乱了，前面谈得再好也会变形。

• ● 按里程碑推进：蓝图确认、配置完成、试运行、正式上线，每个节点对应明确的交付物。
• ● 验收标准先于开发：先写清什么样算合格，再动手做，顺序不能反。
• ● 留出缓冲：试运行阶段发现问题，修整的开销由谁承担，事先讲明。
• ● 尾款比例别太小：尾款是甲方最后的话语权，比例太低就失去了约束力。
• ● 每个节点的交付物写成可检查的清单，别用感觉验收。

图2：开销进出有单据，结算才不扯皮

开销进出都有单据可查，哪笔对应哪个节点、哪个交付物，翻开记录一目了然。这种透明度是结算不扯皮的前提：双方都对着同一份记录说话，争议自然就少。

节奏对齐还有个隐性好处：它逼着双方把项目切成一段一段来管理。每段都有起点、终点和验收，问题在段内消化，不至于攒到项目结束才总爆发。

节点除了挂付款，还可以挂别的东西：培训安排在哪一段、数据接入在哪一段、旧系统什么时候停，都摊在时间轴上。时间轴一摊开，项目全貌就在一页纸里。谁什么时候该干什么，不用猜。

五、边界清楚的合同才好往下走

有经验的厂商不怕边界清楚，反而欢迎。边界清楚意味着交付有标准、结算有依据、双方都有安全感。真正怕谈边界的，往往是打算边做边看的。

• ● 签约前把费用清单逐项过一遍，每项问三句：包含什么、不包含什么、新增怎么算。
• ● 把典型场景写进附件，比抽象的范围描述管用得多。
• ● 建立追加确认机制，所有墙外的需求走同一套流程。

海软CRM在项目启动前就把各类开销列成明细清单的做法，值得当作谈判时的参照：清单越细，后续扯皮的空间越小。遇上主动把边界画清楚的厂商，本身就是加分的信号。

说到底，实施、二开、接口这些名目本身不可怕。可怕的是含糊。项项分明的合同，执行起来反而顺畅；处处含糊的合同，才是项目失控的开端。

把这套边界方法沉淀成企业自己的谈判清单，项目收尾时做一次复盘：哪些边界谈对了、哪些漏了、哪些写法经住了执行的检验。攒上几个项目，这份清单就是企业最值钱的采购资产。

签完字不是谈判的结束，而是执行的开始。把边界谈清楚的企业，执行阶段省下的精力。远比谈判桌上多花的心思值钱。

六、常被问到的几个问题

1、问：实施费到底包含哪些工作，怎么问才不会被绕进去？

答：别问抽象的总包价，直接要一份任务清单：流程梳理、字段配置、数据接入、权限设置、试运行支持，逐项列出工作内容和完成标准。清单越具体，含糊的空间越小。对方若只肯给笼统描述，说明内部对交付范围也没有共识，签约后必然扯皮。

2、问：二开的需求上线后才冒出来，怎么控制追加开销？

答：预设一套追加机制：业务提出需求后，先由厂商评估工时并报价，业务负责人确认签字才开工，逐项留档。这样追加不是不可以，而是每一项都明明白白。同时把追加的累计情况定期汇总回顾，避免小额需求不知不觉堆成大账单。

3、问：接口对接的对象还没定，合同里怎么写？

答：可以按类别约定而不是按具体系统约定，比如写明对接财务类、仓储类系统各几个，采用标准接口还是定制接口，以及超出的部分按什么口径另算。等对接对象明确后，再以补充确认的方式落到具体系统上，既有弹性又留了约束。

4、问：验收标准应该细到什么程度？

答：细到能当场判断合格与否的程度。比如录入一批样例数据走完整流程，输出符合约定的单据和报表，即为通过。凡是需要主观判断的描述，比如界面美观、操作流畅，都要换成可操作的检验动作。标准写不细，尾款结算时必起争议。

5、问：厂商中途更换项目人员，要不要管？

答：要管，而且要提前约定。核心岗位的人员稳定性直接影响交付质量，换人意味着重新熟悉业务，开销和时间都在消耗。签约时可以约定关键岗位更换需提前告知并做好交接，甲方有异议时提出理由。人员流动无法杜绝，但流程上的约束能大幅降低换人带来的震荡。