3.8 平台团队和业务团队谁说了算

云枢科技最初打算让信息团队统一建设所有 AI 项目。设计 YS-P-001 时，销售担心等不及客户身份和权限能力，准备自己购买工具。两个极端都会产生问题：全部集中会远离业务，全部分散会重复建设并失去控制。

两次相反的失败帮助我划边界

信息团队先统一设计销售资格规则，三个月后仍无法覆盖区域和渠道差异；销售团队随后自己购买工具，却用个人账号连接客户资料，也没有统一记录。

第一种失败把业务决定放得离客户太远，第二种失败让共同控制无人负责。我没有继续争论“集中还是分散”，而是逐项判断什么需要全公司一致，什么必须靠近经营结果。

身份、权限、日志、模型接入、成本监控和基本安全由中心能力团队负责。商机到回款、项目交付或客户续约怎样改变，由相应价值流负责人负责。

中心团队不替业务决定客户目标，业务团队也不能绕过共同安全和权限标准。

这种安排常叫联邦式组织。白话就是共同底座统一做，具体业务由最接近结果的人负责，双方通过明确接口合作。

客户身份、员工登录、AI 身份、权限、重要动作记录和费用观察在所有项目中要求相近，由平台团队提供。客户是否合格、哪类承诺需要审批、什么情况允许形成报价，由商机到回款团队决定。

共同数据含义由数据主人确认，专业风险由法务、安全和财务决定。FDE 帮助划分责任，AI 全栈工程师可以属于中心或业务团队，但建设时都遵守相同接口和底线。

中心团队提供能力也要有响应时间和故障责任，不能只发布标准让业务等待。价值流团队获得自主权，也必须对经营结果、采用和例外负责。

统一标准不可能覆盖所有业务。业务团队可以提出例外，但要说明价值、期限、风险和退出方法，由对应专业负责人审查。例外不能变成永久私有系统。

YS-P-001 在 CRM 临时不可用时需要继续维护客户沟通，但这不等于销售可以另建一个永久客户库。我们允许带时间、负责人和最少字段的人工记录；系统恢复后必须核对补录并关闭临时记录。这个例外解决连续经营，不复制共同平台。

如果多个团队不断申请同一种例外，中心团队要更新共同能力，而不是反复责怪业务特殊。例外也给平台提供真实需求证据。

平台与业务可以分别决定自己的范围；涉及跨部门资源和风险接受程度时，由转型小队准备选项，经营层作决定。FDE 不靠个人影响力长期调解。

我通过两个指标检查组织是否有效：业务项目获得共同能力需要多久，共同底线外的经营变化能否由价值流负责人快速完成。任一边长期阻塞，都说明边界或服务方式需要调整。

事项	中心平台团队负责	商机到回款团队负责	专业岗位负责	争议怎样结束
身份、权限、行动记录和暂停	提供共同能力与故障响应	在批准用途内使用并反馈问题	安全确认底线	重大风险与资源冲突交 CEO
客户、合同、项目关系	提供稳定身份、来源和关系机制	提出业务关系并使用确认事实	数据、法务、财务拥有各自权威来源	无权岗位不能自行合并
商机资格、能力、价格和交接规则	不替业务下结论	销售与交付对经营结果和规则负责	产品、财务、法务确认专业边界	目标冲突由价值流负责人提出选项
临时例外	提供申请、期限、记录和撤销	说明经营价值、最大范围与退出条件	对应专业岗位审查	到期自动复核，不默认永久保留

平台团队还承诺：身份和权限请求两个工作日内回应，试点生产故障四小时内给出状态。价值流团队则承诺：规则争议两个工作日内由有权负责人处理，不能把所有业务空白都退给平台。

这张责任表让蓝图从“中心提供底座、业务负责结果”变成了可执行接口，完整版本见共同能力、价值流责任和转型小队。但接口不会自己开会和作决定。下一节要为这些责任安排具体的人、投入、替补和复核节奏：我怎样组建最小转型办公室。