Data Agent，也要像 BI 一样推广吗？

十年前，敏捷 BI 开始进入中国企业的时候，很多企业都遇到过一个相似的问题：产品买回来了，数据也接进来了，但业务人员并没有自然地用起来。

这并不奇怪。敏捷 BI 希望把数据分析能力交给业务人员，但把工具交到业务手里，并不等于业务人员马上具备了数据分析能力。怎么取数、怎么理解指标、怎么设计分析路径、怎么制作看板，都是需要学习的。

于是，过去十多年里，企业逐渐形成了一套相对成熟的 BI 推广方法：选择种子用户，组织分层培训，开展产品认证和技能竞赛，辅导业务课题，评选优秀作品，再通过案例分享、激励机制和内部社区，把少数人的实践扩散到更多部门。

围绕这套方法，"数据公民""数据文化""人人都是数据分析师"也逐渐成为数字化转型中的重要话题。

今天，Data Agent 开始进入企业。很多 CIO、CDO 和项目负责人自然会想到：能不能把这套方法再做一遍？先圈定一批试用员工，培训他们学习 Prompt，组织一次比赛，选出几个优秀案例，然后逐步向全公司推广。

这些工作当然仍然有价值。但如果 Data Agent 只是再按照 BI 的方式推广一次，我们可能会忽略一个根本变化：BI 与 Data Agent 交给员工的，并不是同一种能力。

01 BI 的推广，首先是培养人

敏捷 BI 推广的主要矛盾，是工具已经交给了业务，但业务人员还没有掌握工具。

一个业务人员要真正用好 BI，通常需要掌握数据处理、指标理解、图表表达和分析方法。即使产品已经尽可能降低了技术门槛，使用者仍然要亲手完成相当一部分分析工作，最终做出一张报表、一个看板或者一项分析应用。

所以，BI 的推广首先是一项人的能力建设工作。

培训解决"不会用"，认证检验"有没有学会"，竞赛推动员工把工具用到真实业务中，优秀案例让管理者和其他部门看到价值。企业还会统计参训人数、认证人数、活跃用户、看板数量和打开次数，以此判断推广进展。

这套运营体系背后有一条清晰的逻辑：先培养一批会使用工具的人，再由这些人发现问题、建设应用、形成标杆，最后把能力扩散出去。

在 BI 时代，这个逻辑是成立的。因为 BI 虽然降低了分析门槛，但数据分析能力仍然主要掌握在人身上。人的能力扩散速度，很大程度上决定了 BI 的应用速度。

这也是为什么很多企业的数据文化建设，天然从"人"开始：先找一批愿意学习的人，再通过培训、竞赛和实践，把他们逐步培养成企业内部的数据人才。

02 Data Agent 落地，为什么要先找任务？

Data Agent 与 BI 最大的不同，不只是交互界面从拖拉拽变成了自然语言。

一个具备企业数据分析能力的 Data Agent，可以理解问题、查询数据、切换维度、验证假设、解释结果，并在业务人员继续追问时调整分析方向。员工面对的不再只是一件需要自己操作的工具，而是一个已经具备部分分析能力的数字员工。

这并不意味着员工不需要学习。

恰恰相反，学会正确地向 Data Agent 提问，仍然是落地初期非常重要的工作。员工需要学习如何说明任务、补充业务背景、给出必要约束、判断回答是否符合预期，以及如何通过持续追问，把一个模糊问题逐渐变得清晰。

ChatGPT 刚出现时，Prompt 的学习和分享帮助很多人第一次看到大模型的真实价值。今天，Data Agent 进入企业，同样需要经历这个过程。如果员工连任务都无法表达清楚，Data Agent 的很多能力就不可能被真正打开。

但 BI 与 Data Agent 的学习目标已经不同。

BI 培训更多是在帮助员工掌握一套分析工具，并逐步具备自己完成分析的能力。Data Agent 培训则是在帮助员工学会如何与一个已经具备分析能力的数字员工协作。

换句话说，BI 时代，企业需要把更多分析能力装进人；Data Agent 时代，一部分分析能力已经装进了产品，企业接下来要做的，是让这种能力进入真实工作。

这也是为什么 Data Agent 的落地，不适合简单从"先培训多少人"开始。

如果企业先圈定一批员工，再让他们自由试用 Data Agent，很可能会发生一种情况：大家问了一些问题，觉得产品很新鲜，也看到了一些不错的回答，但几周以后，使用频率逐渐下降。

这未必说明员工不愿意接受 AI，也未必完全是产品问题。更可能的原因是，Data Agent 还没有进入一项必须完成的真实任务。

没有真实任务，员工就很难持续提供完整的业务背景，也没有动力反复验证回答，更不会围绕结果形成稳定的工作方法。最后留下来的，往往只是一些零散的 Prompt，以及几个演示效果不错的问题。

所以，Data Agent 的 0 到 1，更适合先找一项任务，再围绕任务找人。

这里的"先找任务"并不意味着不再运营人。恰恰相反，任务确定以后，企业才能知道应该选择什么样的种子用户，培训什么内容，人和 Data Agent 应该如何分工，以及用什么标准判断试点是否成功。

一项适合早期试点的任务，通常有几个特点：

• 它真实存在，而且会重复发生；

• 过去需要业务人员与数据分析师进行多轮沟通；

• 分析结果能够支持一个相对明确的业务判断；

• 有一个真正理解业务并能够对判断负责的人。

例如，企业每周都要复盘销售波动。过去，业务负责人提出问题，分析师取数并形成分析，业务负责人看到结果后继续追问，双方可能经过多轮沟通才形成判断。如果 Data Agent 能够在同一次交互中参与问题澄清、分析探索、结果验证和解释，人和 Agent 就有可能共同完成从问题到决策的闭环。

这也是 Data Agent 与 AI Coding 不能被简单类比的地方。

AI Coding 大幅提高了代码生成效率，但代码生成只是 DevOps 中的一个环节，后面还有评审、测试、集成和发布。因此，代码生成快了，并不等于产品交付就会以同样的比例加快。

Data Agent 在一些合适的任务中，却有机会覆盖从业务问题到形成决策的大部分过程。人与 Agent 可以在持续交互中完成澄清、分析、验证和判断，而不一定需要把分析结果交给另外一个流程，等待下一轮处理。

当然，形成决策并不等于业务行动已经完成。决策之后的执行和结果兑现，是另外一段价值链。Data Agent 当前首先要证明的，是它能否让人更快、更好地完成从问题到决策，而不是为所有后续业务结果负责。

从这个角度看，Data Agent 早期落地需要建立的，不只是一个优秀用户，而是一个最小的人机决策单元：一个真实任务，一个业务负责人，一个 Data Agent，以及一套能够反复运行的协作方法。

03 Data Agent 的蔓延，首先来自效果

BI 的推广在很大程度上是一种能力扩散。企业通过培训、认证、竞赛和案例分享，让更多人逐步掌握工具。因此，从 1 到 10、从 10 到 100，往往需要持续的组织推动。

Data Agent 可能呈现出另一种蔓延逻辑。

如果一个业务负责人借助 Data Agent，把过去需要反复沟通才能完成的任务，变成了一项可以快速闭环的日常工作，而且这种效能差异足够明显，那么相似岗位的员工很可能会主动学习。

推动扩散的力量不再只来自培训和管理要求，也来自同事之间可以直接观察到的效率差异。

这并不意味着 Data Agent 会自动扩散，也不意味着每个试点都能产生十倍的效能提升。真正困难的仍然是 0 到 1：企业有没有找到一项合适的任务，产品能不能完成它，人和 Agent 能不能形成稳定协作，以及这个效果能不能被复现。

一个有准备的组织，可能通过一项合适的任务，很快看到明显的效能变化。一个没有准备的组织，即使开放了大量账号、组织了多轮培训，也可能只获得一些零散使用，甚至因为验证、沟通和反复修改增加了新的成本。

一旦真正的 0 到 1 成立，后面的推广方式也会随之改变。

Data Agent 的标杆用户，不一定是最懂技术、能够写出最长 Prompt 的人。他更可能是一位真正拥有业务任务的人：知道问题为什么重要，能够向 Agent 补充背景，愿意验证结果，并且对最终判断负责。

企业需要复制的，也不只是他的某一条 Prompt，而是整项任务的方法：

• 问题如何提出；

• 背景如何提供；

• Agent 负责什么；

• 人在哪些地方判断；

• 什么状态才算完成；

• 结果如何进入下一次工作。

因此，Data Agent 的扩散路径更可能是：先跑通一项任务，形成可见效果，再沉淀人机协作范式，最后被相似岗位和相似任务复制。

这里仍然需要种子用户，也仍然需要内部 KOL。只不过 Data Agent 时代的 KOL，不应该只是产品使用高手，更应该是一项人机协作任务的业务负责人。

04 BI 的经验没有过时，只是需要重新组合

Data Agent 的落地并不需要抛弃过去的数据文化建设经验。

高层推动仍然重要，种子用户仍然重要，分阶段培训、优秀案例、激励机制和内部交流也仍然重要。企业也需要给第一批使用者足够的时间，让他们从尝试提问逐渐走向稳定协作。

真正发生变化的，是这些工作的组织顺序和评价重点。

培训不能只围绕产品功能展开，而要进入真实任务；种子用户不能只选择愿意学习的人，还要选择拥有任务和判断能力的人；

竞赛不能只比较谁的问题问得漂亮，而要看谁真正完成了一项有价值的工作，优秀案例不能只展示答案，还要讲清楚人和 Agent 如何分工。

同样，活跃用户数、提问次数和语义调用量可以衡量平台有没有被使用，却不能完全代表 Data Agent 有没有创造业务价值。企业还需要进一步观察：一项任务能不能反复完成，从问题到决策的周期有没有缩短，过去的人与人交付有没有减少，以及这套协作方法能不能被其他人复制。

这意味着，过去 BI 运营中的很多方法仍然可以保留，但需要重新组合：

• BI 的分层培训，要逐步变成基础 Prompt 训练与任务陪跑相结合；

• BI 的看板作品，要逐步变成人机协作完成的真实任务；

• BI 的优秀开发者和分析师，要逐步扩展为懂业务、会判断、能与 Agent 协作的任务负责人；

• BI 的案例推广，也要从复制一张看板，走向复制一套任务方法。

对提供 Data Agent 的厂商来说，责任也不应该止于交付产品和组织培训。

能不能帮助客户发现第一批合适的任务，陪同种子用户跑通协作过程，分辨哪些问题来自产品、哪些问题来自使用，再把成功经验沉淀为可以复制的方法，会成为 Data Agent 服务能力中非常重要的一部分。

过去，一家 BI 厂商的服务能力，体现在能不能帮助客户建立培训、认证、竞赛和应用推广体系。未来，一家 Data Agent 厂商的服务能力，可能首先体现在能不能帮助客户完成第一个真正有效的 0 到 1。

这也会成为企业选择 Data Agent 厂商时，一个越来越重要的判断标准。

企业采购 Data Agent 以后，项目负责人当然需要考虑给哪些员工开通账号、安排什么培训、建立什么激励。但在此之前，也许应该先列出另一张清单：

• 企业准备让人和 Data Agent 共同完成哪些任务？

• 哪些任务经常重复发生？

• 哪些任务长期依赖分析师的多轮交付？

• 哪些任务从分析到判断可形成清晰闭环？

• 谁应该对最终判断负责？

• 如果这项任务被重新完成，业务人员和周围的同事能不能直观地看到差异？

这些问题回答清楚以后，第一批用户、第一轮培训和第一批标杆案例，才会真正有落点。

十年前，BI 推广的核心，是让更多人掌握数据分析工具。今天，Data Agent 落地的核心，是让一种新的分析能力进入真实任务，并在人与数字员工之间形成新的分工。

所以，Data Agent 当然也需要推广。只是它的第一步，不一定是把更多人拉进产品，而是先把一项真正有价值的任务，交给人和 Agent 共同完成。