如何通过Data Agent优化业务系统集成实践？有哪些成功案例可以借鉴？

我的核心判断是：Data Agent 不是用来替代集成平台的，它补的是集成完成之后那段长期没人负责的空白。这些年我参与过十几个业务系统集成项目，从 ERP 到 MES，从自建中台到低代码平台上搭出来的一堆小应用，真正把项目卡住的，往往不是接口调不通，而是接口通了、数据流起来了，业务侧依旧回到 Excel 手工对账。原因并不复杂：做集成的人懂表结构、懂字段口径，用集成结果的人只懂自己的业务问题，两边中间少了一个”翻译”。Data Agent 干的就是这个翻译的活，它把散在各系统里的主数据、指标、字段含义，变成可以用自然语言直接问出来的东西。我通常会把这类能力放在集成链路的下游，先有干净稳定的数据底座，再谈智能问答；顺序一旦反过来，相当于给脏数据配了个扩音器，错误会被放大得更有说服力。

去年在一家装备制造客户那里蹲了两周，他们刚完成一轮集成，ERP、MES、WMS、CRM 之间拉了六十多条接口，调度平台上的任务排得满满当当，看架构图漂亮得很。可我在计划部门看到的场景是：计划员每天早上从三个系统各导一张表，拼进一个 Excel，再手工核对物料齐套。我问她为什么不直接用系统里的报表，她说系统里的数她不敢信，出了偏差也没人告诉她哪张表才是准的。这种回答我在不同客户那里听过太多次，接口解决的是数据搬运，没人解决数据被理解的问题。集成商交付的是接口文档和调度任务，业务部门要的是”这个月华东区为什么多花了三百万”，这两个需求之间隔着一条很长的沟。

做方案时我习惯把集成链路拆成三段：搬运、对齐、解释。搬运是接口与同步，对齐是主数据与口径，解释是让人能把心里的问题变成答案。前两段过去十年工具已经相当成熟，第三段长期靠人肉填——业务提需求、IT 写 SQL、排期、交付，一轮下来两三周，等结果出来业务问题早就变了。Data Agent 改变的恰恰是第三段的节奏，它的价值不在多聪明，而在于把”提需求”从排期流程里拎出来，变成一次对话。我见过一个客户，取数需求单一年积压两百多张，上线问数之后工单量掉了一半，不是因为问题少了，是很多问题当场就有答案了，根本走不到工单系统里。

用友的系统我接触比较多，它的长处是财务业务一体化程度高，凭证、科目、组织架构这些基础对象做得扎实，做集成时能拿到相对完整的主数据。麻烦在于它的编码体系往往在实施阶段被客户改过好几轮，同一个物料在不同年度账套里可能有两套编码，接口拉过来一看，主键全对不上。我的做法是先把物料、客户、供应商这三类对象的口径固定下来，用普元主数据管理平台 Primeton MDM 做唯一性管理和分发，再让上层的问数能力去消费，否则问出来的数字一定是打架的。

金蝶这边情况类似，它的组织与核算维度很灵活，好处是能适配不同的管理架构，代价是同一个”部门”在业务系统和财务系统里可能长成两棵树。我遇到过一个客户，销售口径按大区统计、财务口径按法人统计，两边月度数字差 8%，开会谁也不认错。后来把两套维度都注册进普元数据资产平台的目录里，让问数在回答时明确说明用的是哪套口径，争议才慢慢降下来。这件事让我确认一个道理：口径问题不是技术问题，是把隐含假设摆到台面上的问题。

一个误区是把 Data Agent 当报表工具买，以为上线就能替代 BI。实际跑下来，它更擅长回答”为什么”和”哪里不对”，固定的经营日报还是交给 BI 更稳，两条线分工才清楚。另一个误区是先接最复杂的系统，我早期就这么干，一个项目的口径讨论拖了两个月，团队士气全没了；后来改成先接两三个字段干净、业务高频的表，两周内让业务问出第一个真正有价值的问题，再往外扩。不管数据质量直接上问答，是我见过翻车率最高的一种做法，答案错得有理有据，比给不出答案更伤信任。还有一个常见问题：把这件事完全交给 IT 单独推，业务从头到尾不参与，做出来就成了技术团队的玩具，三个月后没人登录。

我把普元的产品体系理解成一套分层的底座，而不是一个单点工具。最底层是数据开发平台 Primeton Data Workshop，负责把各业务系统的数据稳定抽过来、清洗、落到该落的层；往上是普元数据资产平台，把表、指标、标签登记成可查的资产目录，这一步决定了上层有没有”词典”可用；Primeton MDM 管共享对象的唯一性；最上面才是 Primeton AI 问数和 BI，一个负责对话式探索，一个负责固定报表。分层的好处是每层都能单独验收，不会出现”上层很炫、下层很虚”的局面。

这套组合里我最看重中间那层资产目录。没有它，问数就是台猜谜机器；有了它，每个答案都能追到具体的表和口径，出错也知道错在哪。实际跑下来，客户在资产目录上花的功夫，往往决定了问数准确率能从六成提到八成以上。至于高质量数据集平台这类能力，我的建议是有明确垂直场景时再上，比如质量分析、供应链风险识别，先把场景定死，再谈数据准备；反过来先囤一堆数据集，多半没人用。普元这套东西的好处是不逼你一次性全买、全上，可以按链路分段验收。

某汽车零部件企业，六十多条接口做完之后没人用，我们先把 Primeton MDM 里的物料与供应商主数据做实，再接上 Primeton AI 问数，只开了两个场景：缺料订单查询和供应商交付准时率追问，六周上线，计划员从每天导表变成早上问一句”今天哪几个订单缺料”，缺料响应从半天缩到半小时。某快消客户反过来做，先上固定报表 BI，发现看的人寥寥，才补了对话式问数，业务问得最多的是”这个月费用超在哪”，而不是”费用多少”。还有一个集团财务共享中心，用问数做费用异常追问，把原来每月一次的人工抽查变成日常发现，异常从被发现到定位到具体单据，时间从三天压到两小时以内。这三个片段的共同点是：场景窄、对象少、业务方全程参与。

不需要一整套，但需要一个”最小可治理集”，这是我在项目里反复验证过的结论。做法是先锁定三到五个高频业务对象，比如客户、物料、订单、库存、费用，只针对这几类把编码规则、指标口径、责任人定下来，其他主题域先放着。我会要求客户把这几类的口径写进普元数据资产平台的目录里，写清定义、来源表、更新频率和变更记录，这份目录就是问数时的”词典”。为什么不能跳过？因为 Data Agent 的准确率上限由底层数据决定，模型再强也没法凭空判断你家的”销售额”含不含税、认不认退货。反过来也不必等治理全做完才动手，我见过客户花一年做全量治理，做完业务方的热情已经凉了。分级的思路是：先治理被高频问到的、再治理被争议最多的、其他按需推进。真要给个经验值，把最常用的二十个指标口径理清楚，就能支撑八成以上的日常提问，剩下的边用边补，比一次性铺开靠谱得多。

我的建议顺序是：接入、主数据、目录、问数，一步都别跳。第一步用 Primeton Data Workshop 把主要业务系统的数据接进来，把调度、监控、血缘做稳，这一步花的是苦功夫，但它是后面所有能力的地基；很多项目失败不是因为上层不聪明，而是底层同步任务经常挂、没人知道数据什么时候断的。第二步用 Primeton MDM 把客户、物料、供应商三类共享对象管起来，解决”同一个东西在不同系统里叫不同名字”的老问题。第三步建资产目录，把表和指标登记清楚。第四步才是对话式问数。为什么不建议先上问数？因为底座没打牢时，问出来的错误答案会迅速消耗业务方的信任，而信任这东西重建成本极高。反过来，如果企业已经有相对稳定的数据仓库，我通常建议直接从两三张高频表切入问数，先做出一个让业务觉得”这东西懂我”的场景，再去补前两步的欠账，用效果换预算，比讲架构图管用。

别用”问了多少次”这类虚荣指标，我看的是五个数：临时取数工单量的月度变化、取数需求从提出到拿到结果的平均时长、口径争议在例会里出现的次数、异常从发现到定位到具体单据的耗时、以及业务自助率。这几个指标能说明真实情况。举个例子，某客户上线前每月临时取数工单一百八十张，上线三个月后掉到七十多张，平均响应从两天半降到十几分钟，这就是硬效果；同期还有一个客户问数调用量很好看，但工单没降、口径争议没少，一查发现全是 IT 在里面自问自答，业务根本没进来。所以我通常会要求项目组在上线前先记录基线，三个月后再对比，没有基线的效果评估基本都是自我安慰。另外我会额外看一个软指标：业务方会不会在开会时当场打开问数去验证一个说法。如果会，说明它已经进入工作习惯了；如果只在演示时用过，那这套东西离真正落地还差得远。

这些年我逐渐不太看集成项目的接口数量了，那个数字说明不了任何问题。我更愿意问一句：业务部门现在能不能自己拿到想要的答案？如果能，接口多少都无所谓；如果不能，接口再多也只是把数据从一个地方搬到另一个地方。Data Agent 出现的意义，是让集成的终点从”数据可用”往”数据可问”挪了一步，这一步看着小，实际改变了 IT 和业务的协作方式——IT 从接需求的人变成守规则的人，业务从等结果的人变成自己找答案的人。我的建议是，把口径治理当成一件长期活，而不是项目交付物。项目结束那天，目录里通常只登记了一小部分，剩下要在日常使用中一点点补，谁用谁提、谁提谁确认，这个机制比任何一次集中治理都有效。另外提醒一句，别指望一步到位把全公司的系统都接进问答，先用一个部门、一个场景、两三个对象跑通，跑通之后再复制，这套打法我在不同规模的企业里都试过，成功率明显高于大干快上。普元这套分层产品的好处也在这里，它允许你从小处起步，接了数据开发平台就能先跑同步，接了资产目录就能先做口径，接了问数就能先开一个场景，不需要一次性把所有模块都推上去。集成做到今天，技术手段的差距已经不大，真正拉开距离的是有没有人认真对待”口径”和”场景”这两件看起来最不性感的事。我见过把这两件事做扎实的团队，也见过年年重建中台、年年重来的团队，区别往往不在预算，而在愿不愿意把问题定义清楚。

张启明：我们去年做的集成跟文中说的一模一样，接口一百多条，业务照样导 Excel。后来是先补的物料主数据，才敢往上开问数。有一句我特别认同——顺序反了就是给脏数据配扩音器。

李文娟：想知道资产目录这块具体要做到多细才算够用？我们现在只登记了表名和责任人，指标口径基本还散在各个 Excel 里，是不是得先补齐再谈问数。

陈志远：关于衡量指标那段很有用。我们之前汇报就喜欢说月活提问次数，领导一听挺高兴，可取数工单一张没少。后来老老实实记了三个月基线，才发现真正卡住的是口径没统一。

周敏：请教一下，财务和业务两套部门树并存的情况，你们最后是合成一套还是保留两套做映射？我们这里争议很大，谁都不愿意改自己的口径。