实体企业推AI,可能更需要AI小分队模式

表层拼技术，深层看组织。

推动人工智能在企业落地，有一个感受，AI能否在业务中发挥作用，与人工智能团队和业务的紧密程度、以及人工智能团队是否真正的理解业务高度相关。

但团队经常会讲，很多信息根本不知道，xx没叫我们、这个信息没同步给我，算法模型集成到应用系统里这件事情需要技术支持……

现在想想，问题出在流程和组织层面，实体企业AI落地，组织协同是一个必要条件。

但很多时候把AI当成了一种传统IT技术方向。

和大数据一样，和云一样，把AI团队设置成一个横向的技术支撑团队，然后期待它通过「需求传递→分工协作→拼装交付」的方式，把AI能力注入到每一条业务线。

这个逻辑，在ERP推广历史里，在中台建设的兴衰轨迹里，都出现过相似的困境。

有一点需要先厘清：ERP在自己适合的场景里至今仍是主干。SAP稳稳撑起了全球数以万计企业的财务、供应链、人力体系，这是真实的价值。中台的逻辑也不是错的——在高度标准化、高复用场景里，沉淀共性能力依然是对的。

但ERP和中台有一个共同的属性：它们是为「确定性、长周期、高复用」的稳态IT而生的。而AI是 「不确定性、短周期、场景依赖」的探索性活动。把前者的组织逻辑套在后者身上，才是核心问题。

从散点到集中：重复造轮子时代的痛苦

企业IT的起点，其实是去中心化的。

1960-1980年代，企业IT没有横向概念，各部门各自为政。财务有财务的系统，生产有生产的系统，仓储有仓储的系统，互相之间数据格式不通，月末对账靠人工抄写，误差是常态。

这就是所谓「重复造轮子」时代——每个部门都在解决同一类问题，但用的是完全不同的方案，无法互通。

代价是显而易见的：重复投入、数据孤岛、效率低下。

于是，大家开始寻找答案，答案叫ERP。

ERP：「大一统」的第一次重大实验

1972年，五位前IBM工程师在德国沃尔多夫创立SAP，最初只是做实时财务处理。

1987年，SAP发布R/3，三层C/S架构加上图形化界面，现代企业软件的基本形态就此确立。

1990年代，ERP/CRM/OA全面爆发，一个宏大的承诺随之浮现：把财务、供应链、人力、生产、销售全部统一在一个数据模型下，一个数据库，所有部门共享同一份「事实」。

实践上，ERP在标准化场景里发挥了巨大价值——全球绝大多数大型企业至今仍在用SAP/Oracle支撑核心运营，这是不可动摇的事实。

但ERP的底层逻辑，同样为它划定了清晰的适用边界。

ERP的核心假设是「最佳实践可以标准化」。

SAP用一套全球通用的业务流程模板，要求企业适应它。这套逻辑在流程高度标准化、需求稳定、规模化部署的场景里是极其高效的。

但每一家企业的竞争优势，恰恰在于它独特的业务流程。一旦超出标准化边界，进入需要差异化能力的场景，这套逻辑就会与业务产生张力。

还有一个更深的问题：需求翻译链太长，信息衰减太严重。

业务部门提出模糊痛点 → IT团队翻译成技术需求 → 实施顾问做方案 → 供应商开发 → 交付验收。每一层翻译都会丢失信息。

业务说的是「我想让销售报表更直观」，IT团队听到的是「做一个数据可视化功能」，顾问写成了「开发一个BI报表模块」，供应商交付了一个「支持100种图表类型的报表平台」。

没有人做错，但最终的交付物，可能和业务的原始需求相差十万八千里。

中台思想：「统一能力」的一次实验

2015年前后，阿里巴巴在内部搞了一次大规模架构调整，把分散在各BU的重复能力——用户中心、商品中心、营销中心——统一收归「共享服务中心」，并对外推广为「中台战略」。

一时之间，「中台」成了互联网和传统企业数字化转型的关键词。

中台的逻辑延续了「共享复用」的核心思路，但比ERP更精细——不是替换业务系统，而是把共用能力沉淀成平台，业务线在上面「搭积木」。

2015年到2019年，中台热潮席卷中国企业界。建设业务中台、数据中台、技术中台，成了几乎所有大型企业的数字化「必选项」。

然后，大约在2020年之后，反思开始了。

阿里巴巴在2021年宣布撤销中台体系，将其重新下沉回各业务部门。

中台的困境，核心机制和ERP遇到的边界问题如出一辙。

从2016年到2020年，数据中台成为企业数字化基础设施的「刚需」——统一数据采集、统一数据建模、统一数据服务，是几乎所有有点规模企业的标配投入。

我在实体企业交付数据中台，问题往往出现在后续企业的数据中台运营上，人力不足、需求交付节奏跟不上，变成一个统一收需求、交付需求的地方。有三点原因：

第一，中台天然是横向团队，与业务的距离越来越远。业务提需求，中台评估排期，理解、反复沟通的过程相对痛苦，业务觉得中台交付慢，不懂业务。数据建设周期长，业务需求变化快，数据中台永远在追赶业务的尾巴。等数据中台把某个指标体系建好，业务部门已经换了策略，这个指标体系没人用了。

第二，中台的考核是「能力复用率」，不是「业务价值」。虽说在故事层面，把业务价值包装过来，但核心中台真正的价值是复用。一个中台能力被10个业务复用，不代表这10个业务都提升了效率；但中台会把复用率作为自己的核心KPI，变成一个「追求规模化而非追求效果」的机构。

越是「交付能力」的模式，越容易脱节；越是「对结果负责」的模式，越能真正落地。通用的东西对谁都够用，对谁都没有竞争优势。

中台的故事给出了一个关键结论：横向的技术能力团队，自然漂向「平台维护」而非「业务创造」。 这不是人的问题，是机制问题。

横向团队的绩效逻辑，天然地把团队推向「服务更多业务线」，而不是「把某一条业务线的问题真正解决」。

每一种模式，都在它适合的地方创造了真实价值。ERP在标准化流程管理上至今不可替代，中台在高复用的互联网架构里仍有生命力。

但它们共享同一个属性：为稳态而生——确定性强、周期长、可标准化。

AI的属性正好相反：为探索而生——不确定性高、周期短、场景依赖。用前者的组织逻辑管理后者，是根本的天然错配，不是执行问题。

这是理解「为什么不能把AI当传统IT」的历史基础。

即便如此，企业实践中，最多的还是把AI作为横向技术团队。

横向AI技术团队：最直觉、最普遍、最危险

这是实体企业最容易默认选择的模式，因为它看起来最有秩序——集中一批高端AI人才，统一建设训练平台和推理服务，向业务部门「供货」。

它的典型困境，在大量文献中被记录得清清楚楚。

需求传递的「电话游戏」。 业务说「我想提升客户留存率」，传递到AI团队变成「做一个客户流失预测模型」，交付出来的是「AUC=0.82的XGBoost模型」，但没有人知道这个模型对留存率的实际提升是多少。

需求在业务和AI团队传递过程中严重失真，是AI项目失败最常见原因之一。

交付模型，不交付结果。 一旦作为横向团队，人工智能团队对外提供服务的方式就是交付模型，衡量模型的KPI大多是模型精度，不是业务价值，甚至出现一种扯皮的情况，算法同学说我的模型精度提升了，因为你业务策略的问题导致最终结果不好。

最终，AI变成了炫技，技术上令人印象深刻，业务上毫无用处。

与业务脱节，形成「AI孤岛」。 Deloitte《State of AI in the Enterprise》连续调查发现，以横向技术团队模式运作AI的企业，有高达67%反映「AI能力和业务优先级脱节」是主要挑战。有个大型零售银行（匿名，Deloitte客户案例）建立了50+人的中央AI团队，两年内产出了30+个模型，但只有7个进入了生产系统。

这条路径的机制，和数据中台遇到的困境如出一辙。只是名字换了，逻辑没换。

横向团队天然地被激励去做「横向覆盖」，而不是「纵向深挖」。它沉淀的是通用能力，但业务需要的是情境能力。

我在构思，到底什么是对的？

先说过去为什么是错的？

• • AI作为横向技术团队，被动接需求，并且需求是接口人转述后的。
• • 无法持续深耕一块业务，一个完整需求被横向切割，无法建立全局认知，离业务较远。
• • 人工智能的价值被弱化，算法只能讲清楚模型结果的对比，但讲不清楚对业务的影响。
• • 算法同学只懂模型，缺少工程部署、系统集成、数据等相关专业知识，跨团队协调困难，扯皮严重。

当然，也没有最好的组织形式，不可能把所有的团队变成一个团队，但对AI来说，以小分队的方式推进，可能更接近正确答案。

核心逻辑：构建以AI产品为核心的小分队，小分队包括算法+工程+数据+AI产品四类角色，这个小分队，端到端负责一个或几个业务场景，对接业务，并对业务结果负责。

AI产品是现在产品角色的升级版。需要理解业务流程，以及应用系统（产品）如何在业务流程中发挥作用，但不同的是，需要思考用人工智能升级甚至重塑产品，来更好的支撑业务。AI产品是与业务对话的关键角色。

算法开发、工程技术、数据等角色更多的是理解AI产品的需求、并完成交付。

小分队模式，新的作战单元，共担绩效与考核，持续在一个或几个业务场景中深耕，一个关键标准是，所有人都能讲清楚业务、都能讲清楚需求背后的业务价值。

这个模式在互联网公司里有大量成功案例。一个小分队，绑定一个具体的业务问题（比如「提升短视频完播率」），所有成员都对这个业务指标负责，算法工程师和产品经理、数据分析师在同一个团队里，没有需求翻译，没有中间层。

以上只是一个方向性的思考.

但我能切实感受到的是：在当下内卷+环境下行的情况下， 大家越来越追求可落地性、短期价值的产出直接就决定了生死。而能力是长期的，场景上能否产生价值是短期的。

过去，IT更愿意提能力，但难以掩盖在业务融合层面是不足的，如果AI继续延续这个思路，很难发挥价值，甚至更差。

越是「交付能力」的模式，越容易脱节；越是「对结果负责」的模式，越能真正落地。

往期内容：

IM + Agent + Skills + Knowledge Base：新一代企业软件架构