百丽时尚：企业 AI 应用建设落地实践——从协同在线到 AI 原生

（本文作者为 季燕利，钛媒体经授权发布） 市面上不缺大模型，不缺算法，也不缺 AI 应用。普遍存在的困局是：怎么让 AI 在一家企业里真正落地——理解业务、融入运作、和人一起把事情做好。说到底，这是企业老命题的新一程：信息化提效率，数字化增效益，如今轮到智能化，要的是效能——而效能仅仅购买大模型实现不了，是一种长在业务里的能力，随每一次运转持续进化、按复利累积；先走一步的企业，攒下的从来不止一步。 大多数企业做 AI，是从模型下手的：选一个大模型，做一轮微调，搭一套检索问答，结果是 AI 能“读文档”，却读不懂“业务”，无从进场落地。问题还在企业自身缺三样东西： 一是 业务没在线 ：经营过程散在会议、报表和一线的经验里，系统只记结果、不记过程；企业越大，决策者离真相越远，一线的情况经过层层筛选、解释、加工，常常呈现出“虚假繁荣”，递到桌面上已是一份“超额达标”的漂亮报表。 二是 判断没标准 ：该怎么决策，锁在老师傅的脑子里，换个人，口径就换一套，机器读不出、也学不像；而 AI 给出的建议又是个黑盒：一位经营者可以接受 AI 参谋的建议，却很难接受它的建议无法解释，在要为结果负责的经营决策里，这几乎是致命的。 三是 判断连不成网 ：就算某个环节想清楚了，判断也触发不了下一个动作；决策和执行是断开的，把事串起来、盯到底的，还是人。 三样缺口，根源是同一个： 企业是围着“人”运转的，过程靠人接力、判断靠人经验、执行靠人跟进，它从来没有被整理成 AI 能进场的结构。 模型再强，也读不懂一个没被结构化的企业。所以我们十来年摸索下来的答卷，是把顺序反过来： 别人忙着让 AI 去读懂企业的混乱，我们先把企业自己工程化 ——AI 应用的落地，不是从 AI 开始的，而是从协同开始的。 这条路分三步，每一步补一个缺口。 第一部分·节点 ：用协同在线把业务全过程搬上线、落到一个个具体的节点上，让业务 看得见 。 第二部分·本体 ：把协同沉淀的工程化资产、连同散在人脑子里的门道，翻译成 AI 的认知，让它在一个节点上 看得懂 、算出判断。 第三部分·任务 ：用企业工作台、全局任务中心和助理体系，把成百上千个判断落到任务，连成一张网、盯到底，让判断 办得成 。三步，一步踩着一步：协同攒下的资产，是本体的原料；本体算出的判断，是任务的上游；任务跑完的结果，又回流成更准的认知——每转一圈，AI 就更懂这家企业一分。 这套打法的内核，收成三句话： 决策节点化、群即业务现场、决策即任务 ——业务拆到最小的“决策原子”；群，就是业务真实发生的载体，也是任务被采集、被执行的现场；每一个要动手的决策，都自动落成一个可运营、可管理的任务闭环。顺着这三句走下去，AI 会从一件外挂在业务上的工具，慢慢长成业务自己的一部分——这正是标题所说的：从“ 协同在线 ”，走向“ AI 原生 ”。这里要说明一点：外界说的 AI 原生，是产品天然具备 AI 能力——没有 AI，它就不存在；我们说的，是 AI 生于业务——业务本就立得住，AI 是从结构化的业务里长出来、再随业务一起进化的那部分。 第一部分：节点——搭建协同在线，让业务看得见 一、痛点：业务过程没上线，战略和执行对不上 先从我们实践中一对最有代表性的场景说起：年度预算编制和门店销售目标管理。一个是战略源头，一个是一线末梢，也是协同在线最早落地的试验场。 1.1 断裂的两端：预算编制与门店执行 传统模式下，这两端几乎是断裂的。预算编制像一场“数据苦旅”：目标要顺着一套四级架构逐级传递——从品牌总部，到地区、分区这两层管理单位，再到一线门店，靠 Excel 手工填报、邮件点对点交互，指标一调，各层级就得重新对一轮。预算定完，考验才开始：成千上万家门店、数万名员工，怎样每天朝同一个目标对齐？现实是系统里记着静态指标结果、一线跑着另一套线下数据报表，战略和执行对不上。更麻烦的是过程——分工写得明明白白，可落地的过程没人管，只有结果的校验；财务说“收入”、品牌说“回款”、地区说“实收”，同一个数字三种口径，往上一汇总，数据就打架。 这不单是一家企业的困境。回看传统信息化，企业普遍卡在三处： 数据孤岛 ——各系统口径不一，同一个“销售额”在三个系统里是三个数； 业务断层 ——系统靠接口传数据，业务却靠人一环环接力，端到端没人看得到全貌； 决策滞后 ——数据碎片、管理黑盒，管理者看到的是上月甚至上季度的数。三处痛点，归到同一个根源： 业务过程没有被在线化 ——系统记的是“结果”不是“过程”，数据是静态不是实时，组织关系是滞后不是动态。协同在线要解的，正是这个根源：不为连接而连接，而是让业务过程本身变得可见、可追溯、可校准。 1.2 生长：协同在线是怎么一步步长出来的

图1 ｜ IM工作群：进度统筹、信息透明、实时互动、目标协同 顺着这两端，协同在线是一步步长出来的： 第一步，用“工作群”改变沟通 ：按场景类别，如开关店、收入、商品、费用等，搭起结构化群体系，几百个岗位、几十条流程全纳进来，数据口径、模板、节奏第一次统一。大家在同一套语言下说话，权责更清晰，信息也从“追问才知道”变成“公开透明随时看”，于是“点对点”变成了“网状广播”，过程管理头一回有了载体。 第二步，系统入群、消息驱动 ：预算系统与群打通，进度自动推送、审批直接 @ 到人、填报数据群里随时可查，“人找数”就此变成“数找人”。 第三步，把闭环压到门店一天 ：店长点一张卡片，就把月目标拆到日、拆到人；店员点“报数”实时取数，从做表里解放出来；战报自动播报，闭店自动生成日总结，“群 + 产品”把系统操作、数据应用、管理动作串成一个闭环。 到这一步，一件事被验证了： 工作群，把业务过程管起来了 ；过程一上线，哪个节点出了问题、如何进行调整改进，一眼看得见。 二、地基：四个在线，协同的四套工程体系 工作群要成为业务协同的载体，不能凭空而起，底座由四套工程体系支撑——这就是“四个在线”： 业务在线 决定群能承载多深的业务逻辑， 沟通在线 是一整套大规模组织协同的运行体系，这两个是核心工程； 组织在线 和 权限在线 管住人和边界，是基础保障。 2.1 咬合：四个在线怎么咬成一个闭环

图2 ｜ 协同在线：四套工程体系支撑 它们怎么从战略贯通到落地？拿一个目标的执行来看： （1） 业务在线 把战略目标转成可执行的规则和能力：年度预算拆成各品牌、各店的指标，做成任务卡片派出去，这是“做什么”； （2） 沟通在线 把任务推给对的人、把过程呈现、把结果广播：卡片推到店长群、执行反馈在群里、偏差管理者当场看得见，这是“做得怎么样”； （3） 组织在线 确保执行的人是对的：谁负责哪家店、谁向谁汇报，这是“谁来做”； （4） 权限在线 确保对的人有对的权限：店长看本店、区域看本区，组织一变权限自动同步，这是“能做多少”。 四者咬成一个闭环：一处偏差冒头（某店连续三周没达标），群里的数据就驱动调整、下发新决策、触发新一轮执行。 这个顺序本身，透着协同在线的一条核心逻辑—— 以业务为驱动，而非以组织为驱动 ：先明确“做什么”，执行过程自然会暴露“谁在做、有没有权限、对不对”，再回头校准组织和权限。 2.2 业务在线：从操作侧到能力侧 业务在线是协同的起点，要解决传统 IT“重建设、缺回路”的老毛病：衡量它的不是建了多少系统，而是能不能把业务能力拆成可编排的原子单元、让每一次操作都成为验证数据和规则的回路。这条路分四步： ①系统 （把手工作业搬上系统，是信息化基础工程，不展开） ②业务中台 （以微服务为底座，把业务能力拆解为原子能力，通过微服务化封装，沉淀形成企业共享的中台能力；微服务，即按业务领域拆成的一个个可独立部署、可复用的小粒度服务） ③数据中台 （围绕数据的“进、存、出、管”统一口径） ④前端产品化 （把岗位的标准操作与分析封装成产品，再拆成场景卡片）。真正改变全局的，是后三步。 业务中台，是最关键的一跃。 传统系统面向操作界面：一个个独立的功能集合，能力被封在各自的边界里、无法跨系统复用，更回答不了“过程里发生了什么”。而企业 IT 长年在两个极端间摇摆——“重场景轻能力”，围着一个个场景堆功能，堆出一座座烟囱；“重能力轻场景”，原子能力很强大，却对真实场景考虑不周、用不起来。 工作群，恰是那个难找的平衡点 ：它天然围绕业务场景搭建，又要求底层能力是原子化、高复用的，正好在“场景”和“能力”之间架了一座桥——以场景牵引“需要什么能力”，以原子能力支撑“场景怎么灵活编排”。 落到实处，先看一个例子：过去零售在线下、电商、私域各有一套发券、核销规则，一张券想跨渠道用，得在好几个系统间反复对接，苦不堪言；后来拆出一个统一的“券中心”，哪个渠道发券、用券、核销都调同一套服务，一处顽疾就此了结。业务在线做的，就是把这种“拆一次、全局复用”推到整个公司：业务过程在群里被拆成一个个节点，每个节点的动作抽象成一个独立的原子能力，通过 API 暴露、微服务承载，粒度远比传统功能模块更细。这套重构可以概括为“ 拆、汇、编排、迭代 ”：拆，把大系统打散，提供一个个具备原子业务能力的 API——只做一件事、可被独立调用的最小接口；汇，原子能力汇到业务中台共享、运行数据汇进数据仓库（数仓）统一口径；编排，按业务把原子能力拼成群里的 H5 卡片（H5 即基于 HTML5 的轻量网页，群里点开即用、不必另装应用）；迭代，在闭环里持续校准。能力体系，就此从“散落的工具箱”变成“有序的武器库”。