交付物差异
集成商交付可运行系统与接口文档，产品厂商交付账号与标准功能，咨询团队交付方案、流程与培训。怎么选：要自建能力就找咨询加集成的组合，要快速上线就选产品，别指望一类角色同时给三样东西。
变更响应差异
项目型合同按变更单走流程，周期长但边界清楚；产品型受版本节奏约束，定制需求往往排进路线图；咨询团队响应最快，但改的是方法不是系统。怎么评估：把变更的平均等待时间问清楚再比较，别只看承诺。
上线后责任差异
集成商通常带一段质保与运维交接，产品厂商按订阅提供支持，咨询团队多在结项后退出。怎么约定：上线后的故障谁值班、谁修复、多久响应，直接决定业务能否连续运行，这一条要在合同里写清楚。
对客户团队的要求
集成商需要客户方出接口人与验收人，产品厂商需要业务方自己配置，咨询团队需要骨干全程参与。怎么算：客户投入越少，对供应方依赖越深；评估时要算清自己能出多少人，而不是只看对方承诺多少。
适用与不适用
适合谁
- 正在比较不同类型供应方、需要定组合方式的企业
- 项目处于立项或方案阶段、需要先定角色的团队
- 希望减少上线后依赖、把能力留在内部的组织
不适合谁
- 只需要一次性采购标准软件的场景
- 内部完全没有接口人与验收人的单位
典型场景
某物流企业要改造调度排班，同时接触了三类供应方。最终采用组合：咨询团队先梳理排班规则并培训骨干，集成商负责系统改造与接口，产品厂商提供排班引擎；三方在同一份任务书下分工，每周由客户方项目经理主持对齐。
可执行步骤
- 按交付物把需求拆成方法、系统与标准能力三个部分，分别定价与验收
- 分别接触三类供应方，问清变更响应时间与上线后的责任划分方式与费用
- 先内部评估客户侧可投入的接口人、验收人与业务骨干各有几人可用
- 用组合方式签约，写明三方之间的接口、交付顺序与交接节点与责任
常见坑
- 让产品厂商承担定制集成，交付期被版本排期拖住，业务等不起只能另找一家补做。成本与时间都要重来。
- 咨询团队结项即撤，方法留在文档里没人用，三个月后流程又回到原来的样子。培训等于白做。
- 三方各自签约却没有接口约定，出了问题互相推，客户方反而成了协调方与背锅方。协调成本陡增。
- 客户侧只出一名兼职接口人，需求确认一拖两周，整体进度顺延且难以压缩。最终挤占上线后的运营时间。
自检与验收清单
- 需求是否拆成方法、系统与标准能力三个部分
- 变更的平均等待时间是否问清并写入合同条款
- 上线后的值班安排与故障响应时限是否已经明确
- 客户侧的接口人与验收人是否已经指定并到位
- 多方协作的接口与交接节点是否书面约定、交付顺序
常见问题
能不能一家全包？
可以，但要接受它的短板：全包方通常只在某一段有优势，其余靠外包或标准品补齐。要求它写明分包范围与责任划分，并直接参与关键节点的验收，否则出问题时很难判断卡在哪一环。
小项目也需要组合吗？
不必。范围单一、周期短的项目，一家做完更快。组合适合跨部门、涉及系统改造且需要方法沉淀的场景；判断标准是有没有两类以上的交付物，而不是项目投入的金额大小，也便于后续安排进度。
怎么防止咨询团队撤场后断档？
结项前要求交付可执行的规则文档、培训记录与一名内部接手人，并安排两次回访。把接手人写进合同附件，比在结项会上口头指定更有效，也方便后续追责与安排补课。回访要有记录，不能只打电话。