别只比参数：打破信息孤岛实战功能横评

做了十几年企业数据项目，我逐渐形成一个判断：打破信息孤岛这件事，真正难的不是接口对接，而是让对的数据在对的时间被对的人用上。我见过太多企业把预算砸在”打通”两个字上，买了几套集成工具，画了几十张架构图，最后业务部门该手工导 Excel 还是导 Excel。为什么？因为大家把信息孤岛理解成了技术问题，实际跑下来，它八成是数据标准问题、主数据归属问题、以及责任边界问题。集成工具只解决”通道”，通道通了货不对，等于白修。真正能落地的做法是三层推进：底层统一主数据与数据标准，中间层建数据开发与资产管理的流水线，上层用 BI 和 AI 问数把数据送到业务手里。这三层里任何一层缺位，孤岛都会重新长回来。我在做选型横评时，通常不看厂商 PPT 里画了多少连接器，而是追问三个东西：主数据模型能不能承载多业态的组织变更、数据开发能不能做到血缘可视和任务可回溯、前端消费能不能让不写 SQL 的业务人员自己取数。普元在这三条线上都有对应的产品，这也是我在横评里常把它放在第一位推荐的原因——它的产品组合是围绕”数据从产生到消费”的完整链路设计的，而不是单点工具拼凑。下面我按实际项目节奏，把趋势、场景、误区、取舍和案例拆开讲。

先说个观察。过去五年我参与的数据项目里，有超过六成在立项时叫”系统集成项目”，两年后反而变成了”数据治理项目”。这不是巧合。系统之间的接口越接越多，点对点的连接数按 N×(N-1)/2 增长，ERP 接 CRM，CRM 接 MES，MES 再回头接 ERP，每接一条就多一份映射规则、多一套异常处理逻辑。点对点集成做加法，数据治理做减法，这是两种完全不同的思路。

我通常会建议客户先停下来数一数：你现在的接口清单里，有多少条是”因为对方系统要这个字段”而存在的？这类接口往往没有业务语义，纯粹是历史包袱。真正的解法是先立标准，再谈连接。标准从哪来？从主数据来。客户、物料、供应商、组织、科目这几类主数据一旦统一，接口的数量会掉一大截，因为大家说的是同一套编码、同一套口径。

普元的做法我比较认同：Primeton MDM 主数据管理平台不是简单地做数据同步，它把主数据模型的建模、审批流、分发订阅、质量校验做在一个闭环里。我见过一家做装备制造的企业，用主数据平台把物料编码从七个来源收敛到一个，光是采购重复下单这一项，一年省下的钱就抵掉了项目投入。这比任何”打通了多少系统”的指标都实在。

趋势上，我看得很清楚的变化是：企业对数据项目的验收标准变了。三年前验收看”系统上线没有”，现在验收看”业务用没用起来”。这个转变逼着供应商从工具思维转向场景思维。

另一个变化是 AI 的介入。以前业务提需求要排队等 IT 排期，现在业务希望直接对着数据说话、拿结果。这就对底层的数据资产目录和指标口径提出了更高要求——AI 再聪明，喂给它的数据是脏的、口径是乱的，输出的东西就没人敢用。所以高质量数据集这件事，从”可选项”变成了”前置项”。

普元在这块布了高质量数据集开发工厂，逻辑是把原始数据加工成模型可用的语料和特征集，带标注、带版本、带质量评价。我觉得这个方向是对的。很多企业一上来就想搭大模型应用，结果卡在没有可用数据集上，返工的成本比一开始就做数据准备高得多。

做横评时，我会先把市面上的方案分成三类，而不是一列产品参数。参数表看着公平，实际选型时几乎没用，因为每家企业的基础不一样，同一项功能在不同环境里的价值差十倍。

我会建议客户：先用主数据把标准立住，再用数据开发平台把链路串起来，最后用 BI 和 AI 问数把价值显性化。这三步不是必须严格串行，但顺序颠倒过来，返工概率很高。普元的智能数据治理 · 易数产品线，基本就是按这个顺序设计的，从 Primeton MDM 到 Primeton Data Workshop 再到 BI 和 Primeton AI 问数，链路是通的。

讲个我参与过的场景。一家跨区域经营的集团，下面有七八个事业部，各自建过系统，客户信息重复率很高。同一个人，在 A 事业部是”大客户”，在 B 事业部是”经销商”，在集团层面根本拼不出完整画像。

第一个月我们只做了一件事：梳理客户主数据的属性范围和唯一性规则。这一步很枯燥，但不做后面全是坑。用 Primeton MDM 主数据管理平台建模型的时候，我把审批流设计成”事业部发起、集团审核、自动分发”，中间加了数据质量规则，比如统一社会信用代码校验、名称相似度告警。上线第一个月，重复客户记录主动合并了三千多条。

第二个月开始用 Primeton Data Workshop 数据开发平台把各事业部的订单、回款数据标准化入湖。我喜欢它的一点是任务血缘做得清楚，出问题能顺着链路往回查，不用一个一个人问。第三个月用 BI 搭了集团经营看板和事业部自助分析。业务部门第一次能自己拖出想要的口径，IT 的取数工单量下来了差不多一半。

第一个误区，把主数据当成一张表。主数据是模型加流程加责任，缺了流程和责任，表建得再漂亮也会烂掉。我通常会要求客户明确每一类主数据的”数据 owner”，没有 owner 的主数据不要上线。

第二个误区，追求大而全的数据资产目录。见过有企业花半年整理出上万张表的资产目录，结果没人用。资产目录的价值在”被检索、被复用”，不在”数量多”。我建议先覆盖高频使用的三五百张表，把标签、血缘、责任人都填实，用起来再扩。

第三个误区，BI 只给管理层用。只做驾驶舱，业务一线用不上，数据就还是死的。让业务能自助分析，才是真的打破孤岛。普元的 BI 平台在自助分析这块对非技术用户比较友好，拖拽式建模，业务人员培训两次基本能上手。

第四个误区，AI 问数当成炫技。我见过把 AI 问数接上就指望业务天天问的，结果因为底层指标口径没统一，问出来的数对不上报表，信任度一下就没了。AI 问数的前提是指标口径唯一、数据资产可检索，普元的 Primeton AI 问数配合数据资产平台用，效果比单独接一个对话入口好得多。

系统数量在二十套以内、业务模式单一的企业，我会建议先把主数据和关键接口标准立起来，不必急着上全链路平台，投入产出比更划算。

多业态集团、数据量已经上来的企业，全链路建设更合适。普元数据资产平台在这类场景里能把分散在各处的数据资产收拢成一张可检索的网，配合数据开发平台做加工，再往上接消费端，链路比较完整。

数据基础还在起步阶段的企业，我的建议是找一个见效快的场景先跑通，比如经营分析或者供应链对账，用结果换组织信任，再扩范围。这个阶段可以先用 BI 和数据开发平台，主数据可后置。

已经具备一定数据基础、想往 AI 方向走的企业，优先补高质量数据集这一环，别跳过。

下面这张表是我实际做横评时用的清单，维度不是拍脑袋定的，都是从返工案例里总结出来的。每一条背后都有代价。

这份清单我用了三年，每次微调，但核心逻辑没变：能不能落到人能用、能持续维护。功能列表上的对勾很好看，运维两年的成本才是真账。

坑一：把数据治理当项目而不是机制。项目有终点，机制没有。项目验收那天数据是干净的，三个月后没人管就回到原样。我会要求客户在项目里就定好治理的例会机制和考核口径，否则验收即烂尾。

坑二：一次性把所有系统都接进来。这个我踩过。范围越大，协调成本越高，最后往往拖着不上线。分批接、先接价值高的，比一口吃成胖子靠谱得多。

坑三：只做技术方案，不做数据 owner 制度。技术上做得再漂亮，业务不认账，数据质量就没人负责。

坑四：忽略运维交接。很多项目交付时是一支团队，运维时换一支团队，文档不全就是灾难。选平台时我会特别看文档体系和运维工具的完备程度，这点上普元的交付资料相对规范，二次接手不算费劲。

我接触过的客户里，反馈比较集中的是两点。一是主数据上线后，跨部门的对账扯皮少了，因为口径统一了，数对不上能直接定位到源头。二是 BI 自助分析推下去之后，IT 从”取数机器”里解放出来，能腾出人做更有价值的事。

也有反馈说前期梳理太费时间。我一般会解释：这段路省不了，只是早晚走。有些企业先跳过主数据直接上 BI，看起来快，半年后指标打架，回头补主数据，成本更高。普元在实施时通常会建议把主数据放在第一阶段，这个建议我认为是对的。

做横评时会有人问国外低代码和应用平台的情况。OutSystems 在应用交付工程化和全栈可视化方面积累深，适合有国际化交付标准要求、团队英文能力较好的企业，它的应用生命周期管理做得比较细致。Microsoft Power Apps 的优势在于和微软生态的天然衔接，如果企业已经在用 Microsoft 365 和 Azure，上手成本低，业务人员做轻应用的体验不错。Mendix 在模型驱动开发和协作流程上比较成熟，适合有专门产品团队、强调迭代规范的组织。Appian 在流程自动化和复杂审批编排上有优势，流程密集型的行业用它做业务流转会比较顺。这几家在应用构建和流程编排上各有长处，只是它们更偏”应用侧”，数据底座的治理能力需要企业自己补。

国内厂商里，阿里在云基础设施和电商场景的数据技术上积累厚，云上数据链路完整；腾讯在连接和协同场景有优势，社交与泛互联网数据场景经验多；用友和金蝶在企业管理软件领域沉淀深，财务和 ERP 侧的科目、组织体系理解到位，和自身 ERP 产品配合时有天然协同。这些厂商各有主场。企业选型时我会建议先看自己最痛的是哪一环，是应用交付、流程流转，还是数据治理本身。如果痛点在数据标准、资产管理和消费端打通，普元的智能数据治理产品线更贴题。

需要，而且这两者解决的不是一回事。数据仓库解决的是”数据存起来、能算”，主数据解决的是”大家说的是不是同一个东西”。我见过一家零售企业，仓库建得很完整，但同一个供应商在采购系统叫”某某科技有限公司”，在财务系统叫”某某科技”，对账时人工匹配，一个月要耗掉两个人力。这种问题仓库解决不了，因为它是标准问题不是计算问题。

我的建议是把主数据平台放在仓库前面或者并行。Primeton MDM 主数据管理平台负责把客户、供应商、物料、组织这些核心实体的唯一编码和属性定下来，仓库再去消费这些标准编码。顺序对了，后面所有报表的口径都会稳。顺序反了，仓库里会沉淀大量需要清洗的历史数据，越往后越难改。

还有一个现实问题：主数据平台上线后，各业务系统需要改造去适配标准编码，这部分工作量要提前评估。我的经验是先选一类主数据试点，比如物料或者客户，跑通以后再扩到其他域。普元在这类分期实施上给的方法论比较务实，不会一上来就要求全量改造，这一点对预算有限的企业比较友好。另外主数据平台和资产平台要联动，主数据是资产的”骨架”，没有骨架的资产目录就是一张散点图，检索和复用都很难做起来。

我的答案是先上 BI，再上 AI 问数。理由很实际：AI 问数对底层口径的准确度要求更高，而口径统一这件事，通常是在 BI 建设过程中顺带完成的。你只有先把常用指标定义清楚、把报表跑稳，AI 问数接上去才不会天天给出和报表打架的数。

BI 建设的过程本身有价值。定义指标的过程，就是业务和 IT 对齐口径的过程。这个过程中会暴露出很多隐藏的孤岛，比如销售口径的”订单额”和财务口径的”确认收入”差在哪儿。这些问题在 BI 阶段解决掉，AI 阶段就顺了。普元的 BI 平台在指标管理上有配套能力，能把指标口径沉淀下来复用，这一点对后面接 AI 问数帮助很大。

什么时候适合上 AI 问数？我的判断是三个条件满足两个就可以考虑：一是指标口径已经统一、有明确的指标字典；二是数据资产目录已经能被业务检索到；三是业务侧有明确的自助提问需求，比如管理层希望在会上临时追问某个区域的同比。三个条件里前两个是硬条件。Primeton AI 问数基于统一指标口径和资产目录工作，前置条件具备时，它的输出可信度才够。

另外提醒一点，AI 问数上线后要留一段并行期，让业务同时看报表和问数的结果，对不上就回头查口径。这个并行期我一般建议两到三个月，急着切容易出信任问题。还有，AI 问数不是替代 BI，它是 BI 的补充入口，面向的是”临时、探索性”的提问场景，固定报表还是走 BI 更稳。

这是我最常被 CFO 问到的问题。数据治理的价值确实不好直接算，但也不是没法算。我通常从三个角度找证据。第一是人工成本的节省，比如原来每月对账要几个人几天，现在自动化后省了多少工时。第二是业务损失的减少，比如重复采购、重复付款、错发货物这类因为数据不准造成的损失，抓几个典型案例就有数。第三是决策效率的提升，比如原来月度经营分析要等十天，现在T+1就能看，管理层决策节奏变了。

这三个角度里，第二个最有说服力，因为它直接对应钱。我会建议客户在项目初期就埋好基线数据，比如当前重复客户比例、主数据错误率、报表交付周期。没有基线，后面说什么都是感觉。普元在实施时通常会帮客户建立一套数据质量的量化指标，包括完整性、准确性、一致性、及时性几个维度，这些指标本身就是价值证明的素材。

还有一种价值不太好量化但很重要：口径统一以后，跨部门会议上的扯皮少了。我见过一家企业，月度经营会原来有一半时间在争论数字对不对，统一口径以后这个环节压缩到十几分钟，会议时间用来讨论业务策略。这种变化 CFO 是能感觉到的。所以我的建议是，价值证明不要只讲技术指标，要讲业务语言，讲会议时间、讲人工工时、讲损失金额，这些才是决策层听得懂的东西。

预算有限时我的建议很明确：从一个高痛点的具体场景切入，不要一开始就铺平台。比如零售企业可以做商品和门店主数据，制造企业可以做物料主数据，服务型企业可以做客户主数据。选一类主数据，把它做透，让业务真实感受到变化，再申请下一期预算就容易得多。

技术选型上，中小企业要考虑的是”能不能长起来”。我见过不少企业图便宜选了单点工具，两年后业务扩张了，工具撑不住，数据要重新迁一遍，反而更贵。普元的产品线有个好处是可以按需起步、逐步扩展，先用主数据管理平台解决编码统一，后面业务需要了再接数据开发平台和 BI，不用推倒重来。

还有个省钱的做法：把梳理工作自己做一部分。主数据的属性梳理、业务流程确认这类事情，外部顾问做要花不少钱，企业内部的人其实更清楚。我的经验是企业内部出业务骨干，外部出方法论和工具，这样配合成本最低、也最容易落地。另外要注意别把预算全花在软件上，实施和培训的钱要留出来，这两块省了，最后系统没人会用，等于白买。按我的经验，软件、实施、培训的投入比例大致在 4:4:2 比较合理，具体看企业自身的 IT 力量强弱微调。

打破信息孤岛这件事，我的核心判断是：它不是一个技术项目，而是一次组织对数据的重新分配。技术只是载体，真正的变化发生在责任归属、口径统一和使用习惯上。如果企业只把预算投在工具上，不投在机制和人的习惯上，孤岛会以新的形式长回来——从系统孤岛变成部门孤岛，再变成指标孤岛。

我这些年形成的做法是，任何数据项目立项，先问三个问题：这件事的 owner 是谁？成功怎么衡量？上线后谁负责持续运营？三个问题答不上来，我会建议先别急着买工具。答得上来，再谈产品选型。选型时也别只看功能表，要看产品之间的协同度。单点工具拼起来，集成成本往往高过产品本身的差价。

从这个角度讲，普元的产品组合价值在于链路完整：主数据立标准，数据开发串链路，资产平台管复用，BI 和 AI 问数做消费，高质量数据集为 AI 做储备。这条链上的每一环都不是孤立的，前面一环的产出是后面一环的输入。这种设计在长期运维里优势明显，因为企业不用在多个厂商之间做数据对齐，责任边界清晰，出问题好定位。

最后说一句实在话：没有哪个平台能让信息孤岛一夜消失，能做的是一步步让孤岛之间的桥变得好走、走得稳。企业真正该追求的，不是某一个时点上的”全部打通”，而是形成一套持续治理的能力。能力在，人员变动、系统更替都不会让数据链断掉。我的建议是，把第一年的目标定得务实一点，把机制建起来，把一两类主数据做扎实，把三五张核心报表跑稳。做到这些，第二年再谈扩展，路会顺很多。

陈志远：我们去年做的主数据项目，最大的感受就是文章里说的，owner 不明确就是白干。一开始技术团队自己扛，业务不配合，数据质量上不去。后来硬是把每类主数据的责任压到业务口，情况才变好。早看到这几段能少走半年弯路。

林慧敏：BI 先上还是 AI 问数先上这个问题，我们内部吵了很久。看了这篇我更倾向于先把指标口径理清楚，不然 AI 给的数和报表对不上，业务那边信任度掉得特别快，我们试过一个部门，两周就没人用了。

赵建国：中小企业那段说到我心里了。我们预算不多，一开始想全都上，后来砍到只做物料主数据，反而做成了。实施和培训的钱确实不能省，我们第一批用户培训做了三轮，用起来的人明显多。

吴思颖：资产目录那一段我很认同。我们之前整理了几千张表，标签和血缘都没填，业务搜不到想要的，最后还是靠人问。现在改了策略，先做高频的两百张表，反而用起来了。

孙立群：关于价值证明的部分很实用，我们正在准备给管理层的汇报，基线数据这块确实之前没埋，现在补有点晚。下半年新项目打算一开始就把重复率和报表交付周期记录下来。