一家做职业装的公司，三月份上了一个报价辅助系统。业务员输入客户行业、人数、面料档次，系统三分钟给出一个报价区间和毛利预估。上线三个月，使用率百分之十一。问业务员为什么不用，回答很一致，系统给的价，财务不一定批，批不下来我还要重新算一遍，不如一开始就按老办法。
这不是技术问题。系统算得比人快，也比人准，但它没有权力。业务员要的那个价，需要财务、销售、总经理三方点头，这三方在两个楼层，三个汇报线里。
七月九日的一场 AI 与数字消费论坛上，T3 出行副总裁宋德强介绍了公司引入 FDE 模式的做法，讲的两个词值得注意，端到端，还有组织架构创新承接流程变革。端到端交付这句话被说了很多年，难的是后半句，组织架构要去承接。流程变了，权力没变，流程会自己退回去。
FDE 这个角色在 Palantir 的原始设定里，是一个人带着一支小队进客户现场，从问题定义一直管到指标动。它能管到这么远，靠技术能力，也靠在客户组织里有直接对话的人。这个人通常是业务一号位，IT 负责人很少能担这个角色。
项目挂在哪条汇报线上，几乎决定了它能走多远。
挂 IT 部的，能解决技术问题，解决不了权限问题。数据要开、接口要放、流程要改，每一项都要跨部门申请，一个季度能批下来两项就算快。
挂业务部门的，能改流程，容易被业务自己的短期目标绑住。这个季度冲销售，项目就往后排。
挂董事长办公室或新设的增长单元，能调人也能调预算，代价是要有人真的盯着。这种挂法失败率不低，因为挂上去了，没人日常跟。
三种挂法没有绝对好坏，看两件事。第一件，这个项目要不要改动两个以上部门的考核。要，就必须挂在能改考核的位置。第二件，这条流程一年能带来多少可量化的收益。收益小，挂太高是浪费注意力。
汇报线定完，还要配一个节奏。挂得越高，越容易变成一个月开一次会的项目，中间没人盯。可行的安排是每周一次半小时的碰头，参加的人固定三个，项目负责人、被改流程的部门负责人、财务。半小时只谈三件事，这周改了什么、卡在哪、要谁拍板。这个会开满八周，项目就稳了。
做错的样子有两种。一种是设一个「AI 办公室」，三个人，没有预算权，没有借调权，任务是把各部门的需求收集起来转给供应商。这种机构一般活不过两年。另一种是把 FDE 塞进某个业务部门，让它同时服务三条线，结果三条线都只拿到三分之一的投入。
可以带走的是一张授权清单，三行。
第一行写场景决定权，这个项目做哪条线、不做哪条线，谁定。写在项目负责人名下，不写在委员会名下。
第二行写预算调剂权，项目执行中要挪钱，多少以内可以自己批。很多项目死在第一个月，因为要买一个数据服务，走流程走了六周。
第三行写人事借调权，能直接调用几个业务部门的人，多长时间，原部门不得拒绝。这一行最难谈，也最有效。
还有一件事要在立项时就想清楚，项目结束以后这条汇报线怎么收。挂在董事长办公室的项目，做完以后如果一直不撤，会慢慢变成一个常设机构，人越加越多，事情越做越虚。比较稳的做法是立项就写清退出安排，验收后三个月内这条线并回业务部门，外部团队撤出，只留一个人做日常维护。
希纪在给服装企业做增长诊断时，会看一眼项目启动会的签到表。签到表上全是 IT 和供应商的，这个项目基本只能交付到部门边界。
回到那家职业装公司。第四个月，董事长把报价系统从 IT 挪到了销售副总名下，同时给了财务一条规则，系统算出的区间内，财务不得二次议价。使用率第五个月到百分之六十七。
系统一行代码都没改。改的是谁说了算。
一个可以马上做的检验，把现在这个 AI 项目的负责人叫来，问他上周为了推进这件事，直接找过几个部门负责人。答零个的，说明他还停在技术侧。答三个以上并且都拿到明确答复的，这条汇报线是通的。
希纪 · 服装产业观察