一家钢厂要把一吨钢成本再降 200 元，董事会第一反应往往是：这个AI项目让业务部牵头，还是让信息中心牵头？这道题问错了。在佰工钢铁的落地里，卡住AI进核心业务的从不是"谁挂帅"，而是"谁把业务规则定义成机器能执行的东西"——这件事业务单独干不了，IT单独也干不了，得有一个既懂AI、又懂钢铁、还懂数据/代码/架构的复合型人才，拉到生产现场一起做。
已发布的内容把选型、ROI、数据颗粒度、四层技术路径都拆过了，唯独组织和人才这一层没人碰。本文补上：企业AI落地的组织问题，本质不是"业务还是IT牵头"的站队，而是"谁定义业务规则、谁把它翻译成系统能跑的规范"。
把"业务牵头还是IT牵头"当成一个要拍板的问题，隐含一个错误前提：只要把责任压给某一侧，落地就能推进。事实不是这样。
业务侧懂规则，但说不清规则在系统里长什么样。佰工要算清"刚下生产线的这一卷钢花了多少"，涉及几百甚至上千项指标，每一项都要重新定义：采什么信号、用什么通讯方式、多久采一次、异常值怎么治理、对应什么数据模型、最后用什么算法。这些定义业务人员提得出来目标，写不出字段。
IT侧懂系统，但不懂产线上的专有知识。炉温变化意味着什么、参数波动要不要调整、异常先看哪里——这些在佰工的老师傅脑子里。案例里提到，有人觉得"这是我吃饭的本事，不一定愿意拿出来"，干了几十年的动作成了肌肉记忆，让他转成字段、规则、参数，自己也说不清。佰工钢铁副总经理郭俊成对此的判断很直接："模型可以买，算力可以买，一家钢厂几十年积累下来的生产经验买不到。"
两侧都有缺口，靠"谁牵头"填不上。牵头解决的是责任归属，填不上的是翻译缺口。
业务规则的"所有权"确实在业务侧。一吨钢再降 200 元这个目标，是双边最初定下的；什么算"标准作业"、该优化哪道工序、哪个指标优先，是业务判断，不是技术判断。这点不用争。
但"规则"要变成AI能跑的东西，必须再经过一道：采集点定义、数据治理、算法建模、系统回写。这是另一套语言，业务说不出来，IT没有业务知识也说不对。
所以"业务牵头还是IT牵头"是个伪命题——因为无论哪侧挂帅，都绕不开"把规则翻译成可执行规范"这道关，而这一关不属于任何一侧的本职。真正要决的是：组织里谁来当这个翻译，并且这个人有没有能力在真实产线里把规则定义进系统。
能当这个翻译的人，是一张三维画像，缺一角就转不动。
懂钢铁（行业领域）。 分得清产线上的专有判断，知道炉温、参数、异常背后是哪条业务规则。这一维靠行业年头，买不到。
懂数据/代码/架构（工程实现）。 能把一条规则落成可采、可算、可治理的定义。佰工的细度可以当标尺：轧钢过程中有几百根辊子参与生产，每一根辊子用了多少电都要算出来，甚至需要用微积分算法——在郭俊成看来这属于"最简单的数学模型"，真正的工程量在定义，不在算法。
懂AI（能力边界）。 分得清眼前的问题是建模问题还是定义问题，不被"上多少个智能体"这类数量叙事带偏。佰工最初定的目标只有一个指标——降成本，"没人问要上什么大模型、做多少个智能体"。
这张画像的核心矛盾在于：它既不是纯业务出身能长出来的，也不是纯IT出身能长出来的。业务的人不懂怎么把经验落成字段，IT的人不懂产线经验值多少钱。它只能在"和业务一起拆问题、到现场验证"的过程里被逼出来——这就是为什么人才只能"拉到现场"，不能"招个岗坐在办公室"。
佰工按岗位提人才画像，原话是："我需要这样的人，你们用友应该有，把这个人拉到现场，我们一起做。"这句话的落点不是"派人驻场"这么轻——它定义的是一种共创关系：用友不只提供BIP平台，还提供AI能力、产品服务和工程化人才，双方拆问题、做方案，再到真实生产环境里验证，目标是把验证有效的能力沉淀成产品，向更多制造企业复制。
郭俊成评价这种共创方式："迸发出来的价值非常大，能量也非常大。"他还有一句话更硬，谈到"让AI管理企业"是佰工做AI一开始就定下的前提："如果你做不好这个，我们就不要谈AI了。"
注意这里的场景顺序：先有岗位画像，再拉人现场，再一起做。它恰好说明"谁定义业务规则"不是一个PPT动作，而是在真实生产环境里、由复合人才陪着业务侧逐条把规则落成字段、规则、参数的过程。
这种共创不是靠个人默契，而是被工程化的。用友侧的对应方法是 FDE——前沿部署工程师／前沿共创服务，把"业务 know-how 转移"这个最不可控的环节，变成有人、有时间、有阶段产出的流程。
FDE 分五个阶段推进：
| 阶段 | 干什么 | 产出 |
|---|---|---|
| 场景定义 | 和业务一起拆问题，定场景清单与验收口径 | 场景清单、指标定义 |
| 智能构建 | 按场景做数据准备与算法构建 | 可运行的场景原型 |
| 集成上线 | 接入生产环境，跑通端到端 | 上线记录 |
| 评测运营 | 用真实业务数据验证，持续调优 | 评测报告 |
| 规模复制 | 把验证有效的能力沉淀成产品，向同类企业复制 | 产品化能力 |
第一阶段"场景定义"就是"定义业务规则"的正式环节——业务侧出目标和判断，复合人才把它落成场景清单与指标定义，双方一起签字。配套还有 SDE（软件交付工程）管交付节奏、AI BaaS（业务运营服务）管上线后的业务运营。整条链路强调"到真实生产环境里验证"，而不是在会议室里演示通过。
把"谁牵头"换成"三层分工"，组织问题就清楚了：
业务侧——规则的所有者。 定目标（一吨钢降 200 元）、定什么算标准、定优化对象。这一层不能让渡，让IT拍业务目标，落地会跑偏。
技术/IT侧——底座与集成的所有者。 定采集、通讯、存储、权限、主数据编码。这一层是AI结论可信度的来源，颗粒度下沉到单一岗位时，原有信息系统已经满足不了需求——这是郭俊成的原话。
复合型人才／FDE——翻译与共创者。 把业务规则在真实环境里变成字段、规则、参数、算法，陪跑到验证有效，再沉淀成产品复制。这一层是前两层的接口，缺了它，业务的目标进不了系统，IT的底座接不住业务。
所以"业务还是IT牵头"是伪命题。企业要建的不是一个挂帅部门，而是一支能翻译的复合人才队伍，和一套让他们进场定义规则的工程方法。佰工把成本管理从"月后算账"做到"生产过程中实时纠偏"，前提是有人把一吨钢的规则在产线上定义进系统。
企业AI项目到底该业务部还是IT部牵头？
都不该单独牵头——"牵头"填不上翻译缺口。业务懂规则说不清字段，IT懂系统不懂产线经验。真问题不是谁挂帅，是组织里有没有复合型人才把规则定义成机器能执行的东西。建议三层分工：业务定规则、技术搭底座、复合人才做翻译。
复合型人才（懂AI＋懂钢铁＋懂数据/代码/架构）从哪来？
招不到现成的。它既非纯业务出身能长出来，也非纯IT出身能长出来，只能在"和业务一起拆问题、到真实生产环境验证"里逼出来。佰工按岗位提画像，把用友工程化人才拉到现场共创，借 FDE 五阶段把经验逐条转成字段、规则、参数。
"谁定义业务规则"这句话，落到流程上是哪一步？
落到 FDE 第一阶段"场景定义"：业务出目标判断，复合人才落成场景清单与指标定义并双方签字。佰工把单卷成本拆成几百上千项指标逐一定义，那一步就是规则进系统的地方。
小企业没有这样的复合人才，AI项目还能做吗？
能做，但要把"翻译"这层显式安排出来。自建替代是业务派人全职进项目组，配合厂商 FDE 共创，效果接近、成本结构不同。关键是别让"谁牵头"替掉"谁定义规则"——这层躲不掉，可借厂商工程化人才补，不必全自养。