边界一：流程的通用程度
通用流程用 SaaS，能直接获得成熟实践与持续迭代；特有环节多、且直接影响交付质量时，定制才有意义。判断标准不是我们不一样，而是特例是否影响收入或风险，影响才算真差异，否则只是习惯问题。怎么判断，看特例是否影响收入、交付质量或合规。
边界二：集成与数据要求
需要与多个内部系统双向同步、或数据必须留在本地时，SaaS 的改造成本可能超过定制。此时应评估私有部署或混合；边界在于接口数量与数据级别，而不是产品名气，也不是供应商的销售承诺。为什么边界在接口，因为每多一个接口就多一处对账。
不适用：把系统当解药
流程混乱、责任不清时，任何系统都会被绕开。此类情况应先做流程与授权梳理，再谈选型；用系统解决管理问题，通常得到的是一个更贵的表格，还多了一层维护，最后谁都不满意。怎么排序，先做流程与授权梳理，再谈系统。
不适用：全面定制
支撑性流程全面定制，维护成本高、升级困难，还不产生差异。应先问这段流程是否客户能感知、是否影响中标或交付质量；答案是否定时，用标准产品加配置，把人力留给真正影响收入的部分。怎么克制，问这段流程客户能否感知、是否影响中标。
混合成立的三个条件
混合要成立，需要统一主数据、明确边界与一套集成监控。缺一项，数据就会在两套系统间对不上，最后又要人工核对；边界要写进架构文档，而不是留在口头共识里，否则换人后立刻走样。怎么落地，先统一主数据，再定边界与监控。
适用与不适用
适合谁
- 流程标准化程度较高的职能部门与班组
- 有深度集成需求的制造与流通企业
- 正在设计混合架构的信息化团队负责人
不适合谁
- 期望用一套系统替代管理改进的单位
- 没有主数据管理、却要做混合架构的团队
典型场景
某物业公司要上工单与收费两套能力。工单流程通用，选 SaaS；收费要对接本地财务系统与银行回单，选定制薄层。两者用统一的主数据编码关联，接口失败进入重试队列并告警；边界写进架构文档，避免同一份客户数据在两处各自维护。
可执行步骤
- 判断流程通用程度与特例对业务的影响，逐条打分并留档，供评审用
- 列出集成系统、数据级别与接口方式，估算改造量与人日，并标注风险
- 决定哪些环节用标准产品、哪些做薄定制，写清边界与责任人，双方确认
- 建立统一主数据与集成监控，指定告警接收人与处置流程，做一次演练
- 把边界与责任人写进架构文档，纳入变更评审清单，每季度复核一次
常见坑
- 把管理问题交给系统，流程与授权没改，上线后业务绕行，系统成了台账之外的台账，数据也不可信。
- 支撑流程全面定制，维护成本高，产品升级一次要改半年，团队疲于应付，创新被拖住，士气也受影响。
- 混合架构没有统一主数据，客户编码两套，对账靠人工，错漏频发，财务与业务互相指责。
- 接口没有重试与告警，同步失败无人知晓，月底才发现数据缺失，只能加班补录，影响报表口径。
自检与验收清单
- 特例是否影响收入或风险，是否量化并留档并存档
- 集成系统、接口与数据级别是否列清并做估算
- 标准与定制的边界是否书面化并由双方确认确认
- 主数据是否统一编码，有唯一来源与责任人签名
- 接口失败是否有重试、告警与处置人与演练过
常见问题
怎么判断流程是不是通用？
与行业标准做法逐条对比，看差异是否影响客户或合规。若差异只是习惯，优先改习惯用标准产品；若差异影响交付质量，才考虑定制，否则很容易把管理惯性做成一套只有自己用的系统。
混合架构难在哪？
难在边界与主数据。技术上接口可以写，但两套系统对同一实体的定义不同，数据就会长期对不上；所以先定编码与责任人，再谈接口，顺序反了会一直返工，最后只能靠人工对账。
定制能不能后期换成 SaaS？
可以，但要先把数据导出与流程标准化的功课做足。迁移成本主要不在功能，而在历史数据与例外规则；越早统一主数据，迁移越轻，也越容易说服业务接受标准流程。也很常见。