FDE现实课 02 · 组织授权
企业缺的不是FDE，而是一个敢给FDE授权的人
没有业务负责人、数据Owner和管理Sponsor，再强的工程师也推不动流程。
很多企业把FDE想成一个超级工程师：懂模型、会写代码、能听业务，最好还能处理跨部门关系。
人招到了，项目却没动。
原因常常很尴尬。客服资料归运营，客户字段归销售，接口归IT，审批规则握在中层手里。FDE能写代码，却没有权力让任何一个部门改流程，也不能替数据负责人开放权限。
一个项目最后变成：老板在会上说全力支持，所有人会后继续按原来的方式工作。
工程师不能替组织作决定
企业AI会碰到三类决定。
业务决定：哪一步要改，什么结果算有效，出了错由谁接管。
数据决定：哪些资料能用，谁能看，更新频率和口径由谁确认。
管理决定：哪个部门要配合，原来的绩效如何调整，冲突升级给谁。
这些都超出工程师的天然权限。把决定留空，再要求FDE"想办法推动"，等于把组织问题塞进一个人的工牌里。
一张授权单，比十页技术方案更有用
项目启动前，最好先把六件事写在一页纸上。
• 业务范围：这次只改哪一段工作，不碰什么。
• 结果指标：节省时间、降低错误，还是提高转化。
• 数据权限：能读取哪些系统，由谁批准，如何审计。
• 流程权限：哪些步骤可以调整，哪些必须保留。
• 人工确认：哪些动作AI可以直接做，哪些需要谁签字。
• 冲突升级：部门意见不一致时，谁在多长时间内拍板。
这张纸的价值，不是让项目看起来正式，而是把"支持AI"翻译成可执行的授权。
四个角色，缺一个都容易空转
管理Sponsor负责拍板和协调资源。业务Owner负责解释真实流程、确定验收。数据或系统Owner负责权限和接口。FDE把这些条件变成可运行的系统。
四个角色不能互相代替。
尤其不要让最积极的一线员工默认成为业务Owner。他可能最懂痛点，却未必有权确认流程变化，更承担不了系统出错后的责任。
麦肯锡对企业AI的调查也反复指向同一件事：CEO层面的治理、明确的工作流重构和员工反馈机制，与更好的业务影响相关。技术方案只是其中一环。
FDE入场前，先做一个反向测试
问管理层："如果AI建议和原流程冲突，谁有权决定改哪一个？"
如果答案是"到时候再协调"，项目还没有准备好。
再问业务部门："为了让项目跑起来，愿意提供哪些人、哪些样本、每周多少时间？"
如果答案是"你们先做个效果看看"，那就先做资料检查或离线验证，别承诺进入生产。
企业AI推不动，不一定是员工抵触，也不一定是FDE能力不足。很多时候，企业只授权了一项采购，却没有授权一次改变。
没有改变权，工程师能交付的只有Demo。
参考资料
• Leepriest1990在X上关于FDE与企业流程的讨论
• McKinsey：The state of AI—How organizations are rewiring to capture value
完