交付节奏：配置 vs 开发
SaaS 主要工作是配置、数据迁移与培训，通常数周；定制要走需求、设计、开发、测试，周期以月计。排期时要把数据迁移与培训单列，这两块最常被低估，也最容易拖延，最后压缩的是测试时间。怎么排期，把迁移与培训单列，别混进开发期。
变更方式：提需求 vs 改配置
SaaS 的小改动多靠自己配置，大改动要等产品路线；定制的改动要排期开发，改完还要回归。哪种更合适取决于变更频率与紧急程度，而不是谁更先进；把一年的变更清单列出来，答案通常很清楚。怎么约定变更，写清谁提、谁评估、多久上线。
责任划分：响应 vs 验收
SaaS 的责任多在可用性与支持响应，写进服务条款；定制是交付验收加后续运维，责任在自己或服务商。两类合同的责任边界不同，出问题时处理方式也不同，签约前就要想清楚谁来兜底。为什么责任要写细，因为出问题时看的是条款。
数据归属与导出
无论哪种形态，都要能导出完整数据与配置。SaaS 要确认导出格式、频率与费用；定制要确认数据库与代码的交付范围。数据拿不走，等于把议价权交出去，续费时只能接受对方条件。怎么保数据，先做一次全量导出演练。
失败形态：绕行 vs 烂尾
SaaS 失败常表现为业务绕行、使用率低；定制失败常是工期拖长、功能上线没人用。两类失败都要靠试点与使用率指标提前发现，而不是等验收会才处理，那时预算与信任都已经消耗掉了。怎么复盘，看使用率与变更工单数，不看功能数。
适用与不适用
适合谁
- 需要向决策层解释两种形态差异的负责人
- 正在写采购需求与合同条款的团队
- 已上线一套系统、准备补充另一套的企业
不适合谁
- 只比较功能列表、不看变更机制的采购
- 没有使用率数据、无法复盘的项目团队
典型场景
某集团同时推进客户管理与生产报工：客户管理选 SaaS，两个月完成配置与迁移，后续字段调整由业务管理员自助完成；报工选定制，因为要与产线设备对接。两套系统各自验收，集团要求每月上报使用率与变更工单数，用来判断投入是否值得。
可执行步骤
- 分别列出交付阶段、所需人力与周期，标注关键路径与风险，双方确认
- 写明变更路径：谁提、谁评估、多久上线、如何回归验证，并留记录
- 核对合同中的责任条款、响应时限与升级机制是否可执行，并询问案例
- 确认数据与配置的导出范围、格式与频次，写成附件，做一次试导出
- 用使用率与变更工单数做月度复盘，明确改进项与负责人，形成会议纪要
常见坑
- 排期只算开发或配置，不算数据迁移与培训，上线时间反复推迟，业务方失去耐心，项目被降级。
- 变更没有约定路径，小需求靠人情推动，积累成积压，业务开始绕行，系统逐渐被边缘化。
- 合同只写功能与价格，没写响应时限与责任边界，出问题时互相推，最后只能自己加班兜底。
- 数据导出要额外付费或格式不全，想换系统时被卡住，议价空间消失，续费只能接受涨价。
自检与验收清单
- 交付阶段、人力与周期是否分别列明并确认过
- 变更路径、时限与回归方式是否书面化并留档
- 责任条款与响应时限是否核对过可执行性与案例
- 数据与配置导出范围、格式是否确认并试导出
- 使用率与变更工单数是否纳入月度复盘会议纪要
常见问题
SaaS 的变更会不会很慢？
小改动通常快，大改动取决于产品路线。要区分配置能解决与要改产品两类需求；前者自己动手，后者提前排进路线图，别指望临时插队，否则既拖了业务，也伤了与供应商的关系。
定制一定要自己运维吗？
可以委托服务商，但责任要写清：谁值班、响应时限、版本升级谁负责。没有运维条款的定制项目，上线后往往陷入无人维护的状态，出问题只能临时找人，成本比正规运维更高。
怎么判断上线是否成功？
看使用率与绕行率，而不是看功能是否上线。若关键岗位仍在用表格，说明系统没有解决真实问题，此时应复盘流程而不是继续加功能，否则投入越多，偏离越远。也很常见。也更稳。