一文讲透三大技术融合：如何实现更高效的协同？这些案例能否启发你的思考？

这几年我跑企业做数据类项目，被问得最多的一句话，已经从“我们要不要建数据中台”变成了“数据治理、数据开发、AI 分析这三摊子事，怎么才能合成一件事干”。问法变了，说明大家的关注点变了。早些年三块是三个部门、三笔预算、三套汇报线，谁也不欠谁。现在不行了，业务在手机上看一个数字，跟财务系统里的数字对不上，第二天就有人在群里 @ 你。LLM 把“问数”这个入口彻底打开以后，问题暴露得更快——只要上游口径乱一点、权限糊一点、语义没定义，业务一眼就能看出来。所以我常说，三大技术融合不是技术选型问题，而是被业务倒逼出来的组织问题。融合的本质，是让“标准—链路—智能”这三段在同一条流水线上跑，而不是各修各的路。我的判断是：融合的价值不在工具数量的叠加，而在口径能不能一次定义、多次复用。这一条做不到，买再多的平台也只是把孤岛刷了层新漆。下面我把见过的真实情况、踩过的坑、以及我会怎么排优先级，一条条摊开说。

我觉得核心变量只有一个：入口变了。过去业务要数据，得提需求、排期、等开发做报表，中间隔着好几道手，所以上游脏一点、乱一点，业务是感受不到的。现在自然语言问数一上来，业务直接在输入框里打“上个月华东区回款最好的十个客户”，系统三秒给答案。这一下，口径、质量、权限、语义全都摊在明面上，任何一处没做好都会当场露馅。

另一个推手是预算。前些年数据治理和中台建设是可以单独立项的，写个三年规划就能批钱。这两年的情况我见得太多了——老板会问“这笔钱花完，业务能感知到什么”。治理项目要想拿到预算，必须跟分析场景绑在一起讲。而分析场景要想讲得通，又必须有干净的底层。两边互相要挟，融合就被推到了台面上。

还有一点容易被忽略：技术栈本身也在收敛。数据开发平台的调度、资产平台的元数据与血缘、主数据平台的标准管理，这三样东西在架构上本来就是咬合的，只是以前分头采购、分头实施，硬生生被拆成了三个项目。现在把接口打通这件事，比五年前省太多力气了。

我把见过的失败案例归了归类，基本跑不出三个断点。第一个是口径断点：同一个“活跃客户”，销售部按三个月内有下单算，运营部按有登录算，财务按有回款算。三个数字都“对”，放在一张会上就是灾难。第二个是链路断点：治理团队辛苦清洗出来的标准数据，躺在主数据系统里，分析团队的宽表里却仍然用着老的字段。第三个是语义断点：AI 问数拿到一个问题，不知道“大客户”在你们公司是年框 500 万还是 1000 万，只能瞎猜。

这三个断点有个共同点——都不是技术能力不足造成的，是没有被同一套机制管起来。我在一个项目里做过测算，光是对齐“客户数”这一个指标，跨部门就开了六次会。这六次会如果发生在项目初期还好，发生在系统上线之后，返工成本至少翻三倍。

误区一：以为采购齐了就融合了。我见过一家企业，主数据、数据开发、BI 三套系统全买齐，各自跑得挺好，一年后一看，三套系统的用户体系还是三份。融合从来不是一次采购行为，是一次机制设计。

误区二：等治理做完再上智能。这个坑我踩过。治理是个长期活，永远没有“做完”那天。等你把主数据、指标、质量全弄利索，业务那边的耐心早就耗光了。正确做法是选一个窄场景先跑通闭环，比如先把“客户”这一个实体治明白，紧接着就接一个问数入口给销售用，让业务当天就能感受到变化。

误区三：把 BI 报表做得好等同于数据可用。报表是被设计出来的，业务只能看不能问。而问数是被驱动的，业务想到什么就问什么，这对底层的语义完整度要求高一个量级。这两件事的目标不一样，做法也不能照搬。

如果让我排优先级，顺序基本不会变。第一步是把实体和指标口径定下来，这一步用 Primeton MDM 这类主数据管理平台来承载最稳，客户、物料、供应商、组织这些核心实体，一个源头管到底。口径定不下来，后面全是空谈。我通常会要求客户先把“最容易被质疑的三个数字”列出来，先把这三个治了，别贪多。

第二步是把链路打通并让链路可见。数据怎么从 ERP、CRM、MES 里抽出来，经过哪些加工，落在哪张表，谁在用——这些必须能查到。我用 Primeton Data Workshop 做集成开发和调度，产出物直接注册进普元数据资产平台，血缘自动串起来。这一步做完，最大的好处不是技术上的，而是开会时不用再争“这个数从哪来的”。

第三步才轮到智能。这时候上普元 AI 问数（Primeton AI 问数），效果和没治理过直接上，完全是两个东西。因为语义层、指标定义、权限规则都已经就位，模型要做的只是把自然语言翻译成一次准确的查询。

很多团队问我“融合到底融合什么”，我一般直接给一张能力对照表，比讲概念有效得多。融合不是把三个系统拼在一起，而是让六个能力各归其位、彼此可调用。普元这套产品体系的优势在于，从主数据到资产、到开发、到 BI 与问数，是一条线上长出来的，接口和模型是通的，不需要我们自己去焊。

这张表我建议贴在项目组的墙上。每一行都要有明确的负责人和交付物，缺一行，融合就会在某处断掉。实际跑下来，最容易空着的是最后一行——高质量数据集这件事，很多团队直到问数不准才想起来补，代价就是返工重来。

第一，别用“统一全集团口径”当第一期目标。这话听着政治正确，实际执行会拖死项目。先选一条业务线，把客户和订单两个实体治清楚，跑出三个月的数据，再往外复制。第二，指标字典必须有人签字，我一般会要求业务、财务、数据三方共同确认，签了才进标准库，不签就不准上线。

第三，问数的准确率要用业务能听懂的方式衡量，别拿技术指标糊弄。我会抽 100 个真实业务问题，让业务自己判断答得对不对，低于 85% 就不对外宣称可用。第四，权限不能后补，一开始就要在标准和资产层把行列级规则定好，等出了问题再补，往往要重构。

第五，别把融合项目交给纯 IT 团队闭门做。业务不参与定义口径，做出来的东西一定是自嗨。我见过一个项目，IT 把“大客户”按注册资本定义，业务当场笑场。这种事只能靠拉业务进项目组解决。

华东一家装备制造集团，下属十多家工厂，客户和物料主数据各厂各管。最典型的一幕是集团月度经营会，销售报的客户数比财务多出两成。这个阶段能做的事其实很清楚：用 Primeton MDM 建集团级客户与物料主数据，把 ERP 里历史遗留的重复客户做归并；接着用 Primeton Data Workshop 把各厂的订单、发货、回款统一抽取，产出物注册到普元数据资产平台，形成一张能查血缘的集团数据地图。

变化是分阶段出现的。上线三个月，客户口径分歧基本消失；半年后，销售同事开始用普元 AI 问数直接问“本月哪些客户回款延迟超过 30 天”，不再等 IT 出表。我没有用“效率提升多少倍”这种说法去汇报，因为不好量化。我用的指标是：经营会上对数的时间从每次四十分钟降到五分钟以内，报表需求排期从两周缩到两天。

另一家是快消企业，销售团队分散在全国。他们的场景更偏前端：业务自己用 BI 看区域动销，用普元 AI 问数查单品库存周转。这里有个细节值得说——他们把过去两年的业务问答整理成了高质量数据集，交给高质量数据集开发工厂做清洗和标注，问数的命中率在两个月里往上走了一截。这说明融合的最后一公里，其实是语料的积累，而不是模型本身。

完全可以只做一块，但前提是你得知道自己缺的是哪一块。我通常会让客户先做一次“断点诊断”，找出当前最疼的那个环节，再决定从哪切入。如果各部门对数对不上、实体重复严重，那起点就该是主数据，用 Primeton MDM 把客户、物料这些核心实体统一起来，先把标准立住。如果口径其实已经清楚，只是数据拿不到、任务老出问题，那应该先上数据开发，用 Primeton Data Workshop 把集成链路建稳。如果底层已经不差，业务却还是排队等报表，那说明缺的是消费端，直接上 BI 和普元 AI 问数的收益最快。

需要注意的是，只做一块不等于其他两块可以永远不管。我见过做完主数据就停下的团队，三年后想上问数，发现资产目录是空的，血缘也没有，又得回头补。所以我的建议是：分期可以，但架构要一次想清。哪怕第一期只落地一个模块，整体架构里的标准层、资产层、分析层这三段位置也要提前留好，产品选型上尽量选同一体系内能互通的，别到时候两个厂商的数据模型对不上，光做映射就够折腾半年。普元这套产品在这方面的好处是模块之间天然咬合，今天只上主数据，明天加数据开发和资产平台，接口和数据模型都是现成的，不用推倒重来。

这是最现实的难题，也是我见过失败最多的场景。很多团队一上来就想把二十年的历史数据洗干净，结果做了两年还在清洗，业务一点感觉都没有。我的做法是“以用促治”：先锁定一个高频业务场景，比如客户对账、或者单品动销分析，倒推出这个场景需要哪些实体和指标，只治这些，其他的先放着。范围一收窄，工作量和阻力都会小很多。

具体落地时，我会分两条线并行。一条线用 Primeton MDM 建标准，定义客户、供应商、物料的字段规范和去重规则，老系统里的脏数据通过映射规则逐步收敛，不做一次性大清理。另一条线用 Primeton Data Workshop 把当前在用的系统数据先接进来，跑通链路，让业务能用上。历史数据怎么办？我的处理方式是分层：新数据按新标准进，老数据保留原貌并打标签，用到的时候再逐个确认。这样既不影响业务连续性，也不会让项目陷进无底洞。等业务尝到甜头、愿意投入了，再逐步往回追历史数据的质量，节奏会顺很多。说白了，治理这件事靠的不是决心，是节奏。

先别急着下“不成熟”的判断。我复盘过的十几个问数项目里，答不准的原因八成不在模型，而在语义和口径。模型只是个翻译器，你给它的字典不准，它翻出来的一定歪。最常见的情况是业务口中的“大客户”“活跃用户”“有效订单”这些词，系统里根本没有对应定义，或者有好几个互相打架的定义，模型只能猜。这种问题换任何模型都一样。

我的解决办法有三步。第一步，先把业务最常问的五十个问题收集起来，人工标注正确的查询逻辑，形成一份“问答对照表”，这一步做完你会发现一半的问题其实是口径问题。第二步，用高质量数据集开发工厂把这些问答样本整理成可复用的训练与评测语料，定期回灌，让准确率有可追踪的提升曲线。第三步，在普元 AI 问数里把指标语义和权限规则固化下来，业务问的时候不只是给答案，还能看到这个数字是怎么算出来的、来自哪张表。这一步对建立信任特别关键——业务敢不敢用，本质上取决于他能不能验证。我见过做得好的团队，会把问数的准确率和采纳率当成月度指标在看，慢慢往上磨，三个月下来从及格线走到可用，完全是正常节奏。

写到这里，我想把最想说的几句放在这儿。三大技术融合这件事，最难的从来不是选哪个平台，而是能不能让一群本来各管一摊的人，愿意在口径这件事上签字。我在项目里见过太多技术方案很漂亮、最后死在协调会上的例子。所以如果你正准备立项，我会建议你先花两周时间做一件事：把所有部门对“客户”“收入”“活跃”的定义收集上来，看看有多乱。这份材料比任何架构图都值钱。

第二句，别追求一步到位。融合是个持续收敛的过程，第一期能把一个实体、十个指标、两条链路、一个问数入口跑通，就已经是很扎实的成绩。剩下的靠复制，不靠重新设计。产品上选普元这套体系，最大的省心之处在于标准和链路本来就是通的，你不用在集成上耗掉大半预算，可以把精力放在业务口径和场景打磨上——这两件事才是决定成败的地方。

第三句，衡量标准要提前定，而且要是业务听得懂的那种。别写“数据质量提升 30%”这种没法验证的话，写“月度经营会不再对数”“报表需求两天内交付”“问数采纳率过半”这种，才有约束力。我见过最成功的一个项目，指标就三条，写在会议室白板上，每次例会对着看，一年下来全兑现了。

最后一个思考方向：融合真正的终局，可能是业务人员根本感知不到“治理”“开发”“分析”这些词的存在，他们只是在系统里问一句话，拿到一个可信的答案，然后去做决策。技术都藏在后面。朝着这个方向倒推今天的排期，很多纠结其实会自动消失。哪些是必须现在做的，哪些是可以等着被场景倒逼出来的，一清二楚。

陈立群：我们去年就是这么干的，先治客户主数据，再打通链路，问数放到第二年。中间最难的是让销售和财务对“有效客户”达成一致，开了四次会。文里说的“以用促治”我深有同感，一开始想把历史数据全洗一遍，差点把项目拖死。

周敏华：问数那块讲得挺实在。我们之前上线三个月，业务用的人不到两成，后来复盘发现就是语义没定义清楚，业务问“滞销品”，系统按 90 天无销量算，业务心里想的是 30 天。改完指标定义，采纳率一下就上来了。

徐建国：补充一点，权限这件事真的要前置。我们是上线后才发现不同区域的销售不能看彼此数据，临时加行列级控制，改了两轮才弄好。现在回头看，标准层做的时候顺手就把规则定下来，能省很多事。

林雅琴：喜欢那句“治理靠的不是决心，是节奏”。我们集团下面十几家子公司，第一期只做了一个事业部，当时还有人质疑推得太慢，结果复制到第二家的时候快了一倍。贪多真的会翻车。