6.7 三个项目都叫客户风险，为什么不能共用一个字段

第七周，订单到上线团队开始接入系统。工程师发现自己又在建设员工身份、客户关系、资料来源和重要动作记录。商机到回款已经做过一遍，客户续约的诊断方案里也出现了相同需要。

平台负责人提出建立统一的“客户风险中心”。销售、交付和客户成功都可以共用一个红黄绿字段，所有规则也由平台维护。

第一次评审只用了十分钟，三个部门就为“红色”代表什么争论起来。名字相同的字段，正在遮住三种完全不同的经营判断。

案例说明：本章项目、接入时间和平台决定均为虚构教学设定。共享边界必须按真实公司的责任、风险和变化速度重新判断。

同一个“风险”，三位负责人说的是三件事

价值流	红色风险实际表示	谁能改变判断	错判的经营后果
商机到回款	客户承诺、价格或合同事实尚未确认	销售、售前、交付、财务或法务按事项决定	错误方案发出，范围和毛利受损
订单到上线	已签订单缺少账号、资料、资源或客户负责人	项目经理确认启动条件	项目时钟提前开始，验收和回款被拖延
问题到续约	使用、工单、关系或客户目标显示可能流失	客户成功负责人组织行动并确认	团队过早打扰客户，或错过真实风险

如果平台把它们合成一个红色，员工不知道该找谁，也无法比较历史。共同客户身份可以共享，含义不同的业务状态不能因为名称相似就被强行统一。

三个项目的需求叠在一起后，出现两组明显不同的能力。

能力	出现在哪些流程	是否随经营目标频繁变化	决定
员工和 AI 独立身份	三条价值流	否，底线基本相同	共享
客户集团与签约主体关系	三条价值流	关系本身较稳定，确认责任一致	共享事实与来源，不共享业务结论
访问范围、重要动作和暂停	三条价值流	控制方式基本相同	共享
CRM、合同和项目系统的稳定连接	两条以上价值流	连接共同，允许字段按授权不同	共享连接能力
客户是否合格	商机到回款	随市场与销售策略变化	价值流拥有
项目是否可以启动	订单到上线	随交付方法与客户条件变化	价值流拥有
是否采取续约行动	问题到续约	随客户策略和责任变化	价值流拥有
某团队的多媒体资料处理	一个产品实验	尚无第二个真实使用者	留在项目内

判断很朴素：每个项目都必须可靠完成、而且不随业务目标变化的控制，适合共享；需要对经营结果负责的人频繁调整的规则，留在价值流附近。

共享不表示项目把责任扔给平台。我们为首批共同能力写下服务约定。

共享能力	平台负责什么	价值流仍负责什么	当前承诺
身份与权限	开通、回收、记录和故障恢复	说明用途、范围和岗位授权	标准申请 2 个工作日；紧急撤权立即处理
客户关系与来源	保留集团、法人、联系人关系和确认来源	决定这些事实在当前业务意味着什么	冲突不自动合并，显示当前主人
重要动作记录	保存对象、动作、版本、人工决定和时间	定义哪些动作对业务重要	关键事件可按订单和客户查回
稳定系统连接	管理获准读取、变更通知和恢复	处理连接中断后的业务人工路线	故障 4 小时内给状态，恢复后协同核对

平台团队看接入时间、可用性、恢复和重复建设减少，不能只报告做了多少连接。价值流团队看经营结果、采用和例外，不能把平台故障以外的问题都推给中心。

第一，它已经在真实流程中工作，不是只存在于架构图。第二，至少两个价值流确有相似需求，共享后能减少重复，并且不会把业务决定收走。

区域隔离能力已经服务 FR-25-42，但第二个需求仍在评估，所以只进入候选，没有立刻建设成公司平台。客户身份、来源和日志则已经被商机到回款和订单到上线共同使用，因此获得限定资源。

这种顺序允许平台跟着业务证据生长。它可能不够宏大，却能防止公司用半年建设一个没有真实服务对象的“统一智能底座”。

YS-25-071 同时关联客户集团和华东签约主体。平台正确显示两者关系和来源，但没有替销售决定合同主体；订单价值流根据正式合同确认签约方，项目价值流继续读取同一个法人事实。

销售负责人随后调整了“非标准承诺”的业务规则，不需要等待平台发布。平台只记录规则版本和受影响对象。共同部分稳定，业务部分仍能变化，这才是边界通过的证据。

运行手册 0.7 固定了第一批共享能力、服务对象、响应、费用归属和故障责任。下一周，这个边界立刻接受了更难的检验：一个周末同时改变了合同模板、产品名称和判断规则，周一提醒数量突然变成原来的三倍：提醒为什么突然多了三倍。