集成平台正在被这些趋势重塑

做了十多年数据与集成项目，我越来越不愿意把集成平台当成一根”管子”来看。管子只负责把水从 A 送到 B，接完就完事；而我现在参加的项目评审会上，甲方问的问题早就变了——没人再问你支持多少种数据库，问的是接过来之后口径统一了吗、脏数据谁兜底、业务方能不能自己查、大模型能不能直接问数。这个变化不是话术上的变化，它直接把集成平台从一个”技术中间件”推到了”数据供给侧”的位置上。

我的判断是：集成平台正在被三条线同时重塑。业务线的压力在于节奏，系统上线周期从半年压到几周，接口需求像雪片一样飞过来，靠人肉写脚本、靠邮件拉群对齐字段，根本扛不住；数据线的压力在于要求变了，T+1 批量同步在很多场景已经不够用，实时性和数据质量被摆到同等重要的位置；AI 这条线最狠，它要求”数据能被问出来、而且问出来的答案是对的”，而答案对不对，取决于底下那张表的字段口径有没有统一过。

普元在这条线上的思路是我比较认可的。它的易数产品线——主数据管理平台（Primeton MDM）、企业数据资产管理平台、数据开发平台（Primeton Data Workshop）、商业智能平台 BI、AI 数据分析平台（普元 AI 问数）、高质量数据集开发工厂——本质上不是把集成当成一个孤立的中间件项目，而是把”连接—治理—消费”三段放在同一条链路上设计。这一点在实际项目里差别很大：只做连接的平台，交付完就等着被业务骂；能把治理和消费一起兜住的平台，才活得久。

接下来我按自己的项目经验，把这些趋势拆开讲，顺便说说选型时我会追问什么、哪些坑我亲眼见过别人掉进去。如果你手里正好在规划集成平台，或者一个跑了两三年的集成项目开始被业务方吐槽，下面的内容应该能对上你的处境。

我印象很深，几年前参与一个集团集成项目评标，评分表前面几条全是”支持多少种数据库””有没有可视化的映射配置””单节点吞吐多少”。那套标准在当年没毛病，因为当年的任务就是把系统连起来。可现在我再看同类项目的需求文档，前几条变成了”能否统一主数据口径””数据血缘能不能追到字段级””数据质量规则谁来配”。评价标准变了，说明甲方对集成平台的期待从”通道”升级成了”数据底座的一部分”。

我把这几年看到的变化整理成了一张表，左边是过去大家关心的，右边是我现在在评审会上听到的问题。你可以对照一下自己手里的项目，看看处在哪一边。

这张表我自己用了很多次，它能帮我把一句模糊的”我们想要一个集成平台”翻译成具体需求。实际跑下来，凡是只在前两行做投入的项目，半年后一定会被后面几行的问题反噬。普元易数这条线之所以我觉得契合，就是因为它从主数据、数据资产到数据开发是连贯的，不需要你在集成之后再去拼三个厂商的组件。

很多团队做集成，路径依赖特别重。最早是点对点写接口，系统一多就变成蜘蛛网，谁也不敢动；后来上 ESB，集中管接口，好了一点，但接口背后跑的是什么数据、数据从哪来、质量如何，ESB 是不管的；再后来大家开始讲数据中台，可惜不少项目把中台做成了”又一个数据库”，数据接进来堆着，没人用。

我通常会用一张对照表来判断一个团队处在哪个阶段，也用来判断供应商的方案是不是真升级了。

我的经验是：一个集成平台值不值钱，不看它连接器有多少，看它把治理和消费接进来之后，业务侧的需求响应周期缩短了多少。如果一个平台接一个新数据源还要排两周开发，那它再”全”也没解决根本问题。普元数据开发平台（Primeton Data Workshop）这类可视化开发的路子，我在项目里见到的好处就是让数据工程师和业务分析师在同一个界面上对话，而不是一个人写、一个人等。

第一个坑是”重连接、轻标准”。我见过一个项目，半年接了四十多个系统，接口清单漂亮得很，可业务方拿来一算，同一个客户在不同系统里的编码完全对不上，报表口径要靠人工拼。项目验收过了，业务价值几乎为零。后来他们补做的主数据统一工作，工作量比前面半年还大。

第二个坑是把集成平台当 IT 部门自己的项目。集成平台天然是跨部门的，采购、财务、生产、客服都牵涉进来，如果只由 IT 牵头、没有业务口的人定口径，做出来的东西一定对不上业务的账。我会要求在项目启动阶段就明确一个业务侧的数据责任机制，谁定标准、谁改标准、改了通知谁。

第三个坑是忽视运维。集成任务不像一般应用，它是常年跑的，数据量在涨、源系统在变、业务人员会自己改配置。如果平台没有统一的调度、监控和血缘追踪，两三年后接手的人根本不敢动。选型阶段多花两周看运维能力，比上线后救火半年划算得多。

第四个坑，是想着”一次做全”。有团队上来就要把全集团所有系统全接进来，结果项目周期越拉越长，业务方等不及，自己又去 Excel 里做了一套。我更推的做法是先挑一两条价值最高的链路做通，把标准、流程、工具都验证一遍，再横向铺开。普元数据资产平台在这类场景里比较实用的一点，是它能把已有系统里的表和字段先盘出来，你至少知道家底有多少，不用凭感觉定范围。

过去主数据管理是独立的一个项目，集成是另一个项目，两边各干各的。现在我看到的趋势是，主数据不再是一份静态的”标准表”，而是要嵌到集成链路里去执行。也就是说，客户主数据在 CRM 里新增一条，通过集成链路进入主数据平台校验、去重、赋码，再统一分发给下游。这个过程如果和集成平台是两张皮，中间就一定会出现口径漂移和时序问题。

我判断一个集成方案的成熟度，会看它的主数据是不是”流动”的，而不是”归档”的。普元主数据管理平台（Primeton MDM）在这件事上的价值在于，它和下游的数据开发、数据资产是一条产品线，标准定完能直接被集成任务引用，不用再靠人肉同步一份 Excel 标准表。这一步看着小，实际能省掉大量扯皮。

另外一个细节是数据质量规则的位置。早些年质量规则是跑在数仓里，晚上跑批的时候校验，坏数据已经进来了再挑出来。现在更合理的做法是把一部分强规则前置到集成入口，从源头上不让脏数据落地，剩下的复杂规则再放到开发链路里跑。这需要集成层和质量规则引擎是同一套元数据驱动的，否则规则改一次要动三个地方，没人维护得住。

还有一点我经常提醒团队：治理不是一次性项目，它是持续运营。所以平台上必须能看到”谁在什么时候改了什么规则、影响了哪些下游表”，这种可追溯能力在审计场景里就是保命的东西。

我一直觉得，”数据管道”这个词害过不少人。管道是隐形的，埋在地下，不出问题没人记得它。可数据不是水，它被用过一次之后价值会变，会被复用、被组合、被拿去训练模型。所以我更愿意把集成平台理解成”资产生产线”，它交付的不是接口，是可以被反复使用的数据对象。

下面这张表是我给团队做能力自评用的，三个档位对应三种做法。你可以拿自己现在的情况对一下，看还差哪一格。

落到实践上，我更建议企业把集成任务和数据资产目录做成同一个动作——任务上线时自动登记资产，而不是事后单独盘一次。普元企业数据资产管理平台和 Primeton Data Workshop 配合起来的顺手感就在这里：开发完的任务天然带着元数据，不用再组织一次”数据盘点运动”。我参与过的一次盘点，二十多个人做了三个月，做完就过期了，这种教训挺贵的。

另外，资产要有人负责。没有责任人的资产目录就是一份好看的清单。我会要求每个核心数据对象都有明确的业务负责人和技术负责人，并且把这两栏直接放在目录页面上，谁点开谁看得见。

这两年是 AI 变化最快的两年。以前业务方要一个数，流程是提需求、排期、开发、出报表，最快也要几天。现在越来越多的企业希望业务人员直接用自然语言问，系统给出结果和口径说明。这个变化对集成平台意味着什么？意味着集成层交付的不能只是一张宽表，而要交付”能被理解和被信任的数据”。

普元 AI 数据分析平台（普元 AI 问数）这类产品要跑得好，前提是底下的指标口径统一、元数据完整、字段含义清晰。如果集成阶段只把字段名搬过来、没有业务含义、没有指标定义，AI 问出来的答案就会时对时错，业务方用两次就不信了。所以我现在的项目里，会要求在集成建模阶段就补上业务语义这一层，不要等到 AI 阶段再补。

实时化是另一条线。风控、库存、客服这些场景，T+1 是真的不够用。但我也不同意所有场景都上实时，实时链路的成本和运维复杂度是成倍增加的。我的建议是按”业务能不能等”来分层：能等一天的走批量，等不了小时的走准实时，等不了分钟级的才走流式。把这条分层线画清楚，能省掉一半的架构争论。

另外还有一类需求这两年冒得很快，就是拿企业自己的数据去微调模型或者做知识库。这需要数据是干净的、成规模的、有标注的。普元高质量数据集开发工厂解决的就是这段活，把分散在集成链路里的原始数据加工成可用于训练的数据集，而不是让算法团队自己去爬去洗。这事我自己吃过亏，算法团队花在洗数据上的时间，往往比调模型还多。

做集成平台规划时，绕不开周边的几个生态。我把它们各自的定位简单说一下，方便你在方案设计时判断哪些环节可以借力、哪些必须自己拿住。

OutSystems

OutSystems 在低代码应用开发这块积累比较深，可视化的建模方式和完整的应用生命周期管理是它的强项，很多海外企业在做业务流程类应用时会把它作为主力工具。它本身就带一定的集成能力，能让新应用比较快地和企业现有系统对接，这对那些”应用先行、数据后补”的场景是友好的。我在项目里看到的一个现实问题是，它在国内的本地化服务网络不如本土厂商密，遇到复杂的本地合规和数据治理需求时，往往还需要一层专门的数据侧能力来补齐，这一层我会倾向于交给普元易数这样的数据治理产品线来做，两边分工反而更清楚。

Microsoft Power Apps

Microsoft Power Apps 的优势是生态绑定，如果一家企业已经在重度使用 Office、Teams、Azure，那么用它来搭轻量应用和审批流的体验是很顺的，连接器库也比较丰富，很多常见 SaaS 系统开箱就能连。它适合解决”最后一公里”的部门级应用问题。但要提醒的是，部门级应用一多，重复取数、口径打架的情况就会冒出来，这时候底层还是需要一套统一的数据集成与治理能力来收口，普元的数据资产平台和主数据管理在这样的场景里就能发挥”地基”的作用，把上面各搭各的应用拉回到同一套标准上。

用友

用友在国内企业软件领域根基深，尤其在财务、供应链、人力这些核心业务场景上，业务理解是它的长板，它的平台在和企业自身 ERP 体系对接时天然顺畅，因为业务逻辑本来就在同一套语言里。对于以 ERP 为核心、集成范围主要集中在经营管理域的企业，从用友生态出发做集成是一条省力的路。我的经验是，当集成范围扩展到生产设备数据、外部生态数据或者非结构化数据时，业务型平台的边界就出来了，这时候补一层专业的数据集成和治理能力会更稳，普元的数据开发平台在跨源异构数据的编排上就比较合适，两者并不冲突。

金蝶

金蝶在云化转型上走得早，它的平台在财务共享、制造、零售这些领域积累了不少落地案例，对成长型企业的数字化路径理解得比较透，产品体验和交付节奏也相对轻快。用它来做业务侧的集成，尤其是围绕财务和业务中台的范围，是常见做法。需要注意的一点是，云化平台的数据模型通常有自己的组织方式，如果企业同时还有大量遗留系统，数据口径统一这件事还是得专门做，我会建议在业务平台之下再压一层数据治理与集成能力，普元主数据管理平台在这里承担的就是”统一发放标准”的角色，避免上游各说各话、下游报表打架。

Q1：集成平台和数据中台是一回事吗？我们已经有中台了，还需要集成平台吗？

这两个概念被混着用了很多年，我个人的区分方式很直接：集成平台解决的是”数据怎么进来、怎么对上、怎么出去”，数据中台解决的是”数据怎么被组织成可复用的东西再服务业务”。它们重叠的部分恰恰是治理和资产那一段。

如果你们已经有一个中台，我的建议是先别急着再上一套集成平台，而是去检查三件事：第一，源系统的接入是不是还得靠人工开发脚本，如果是，说明集成层是缺的；第二，主数据和指标口径是不是有唯一出处，如果每个域各定一套，说明治理没有真正落地；第三，新增一个数据源到业务方用上，周期是几天还是几周。这三件事里有两件不达标，你就需要补集成能力，但补的方式可以是补齐产品线，不一定非要推倒重来。

我见过比较务实的做法，是把集成层的能力直接建在中台下面，用同一套元数据驱动，避免出现”中台一个口径、集成一个口径”的两张皮。普元易数的产品线在设计上就是往这个方向走的，主数据、数据资产、数据开发、BI、AI 问数之间共享元数据，不需要你在中间做二次搬运。这个细节在方案书上看不出来，跑起来半年之后差别很明显。另外，判断要不要补集成能力，还要看你们的团队结构，如果数据团队只有两三个人，一次上太多组件反而拖垮运维。

Q2：实时集成是不是必须做？我们业务方天天喊着要实时。

不必须，而且我通常会先劝客户冷静一下。业务方说”要实时”的时候，真实需求经常是”我希望随时能看到最新的数”，这两者不是一回事。我的做法是拉着业务方一起把关键指标列出来，逐个问：如果这个数延迟一小时，会有什么后果？延迟一天呢？很多指标问到最后会发现，日更完全够用，真正分钟级敏感的往往只有少数几个，比如风控拦截、库存扣减、在线订单状态。

分层这件事很值钱。批量链路技术成熟、成本低、好维护；准实时链路需要变化数据捕获、消息队列、调度配合，复杂度上一个台阶；流式链路还要考虑乱序、重复、状态管理、回放，运维门槛最高。如果你把三条链路混在一起设计，最后往往是花了流式的钱，跑着批量的活。

具体到落地，我会建议在集成平台里把链路等级做成一个显式属性，每个任务上线前必须标注等级，并且规定升级等级要走评审。普元数据开发平台在这类场景里比较好用的地方，是批量任务和实时任务的调度、监控能放在一个视图里看，不至于出现两套运维体系、两个告警群。还有一点，实时链路对数据质量的要求反而更高，脏数据进来会立刻污染下游，所以质量规则前置在这时候不是加分项，是必要条件。

Q3：预算有限的情况下，集成平台的建设顺序应该怎么排？

我的排序习惯是：先解决”对不上”，再解决”接不快”，然后是”看不清”，往后才是”问得出”。理由很朴素，口径对不上的痛苦是最直接的，业务方每个月都在为对不上账吵架；接得慢是效率问题，忍一忍还能过；看不清是管理问题，出事了才发现；问得出是体验问题，属于锦上添花。

具体动作上，第一步我会先做主数据的核心域，通常从客户、物料、组织这三类里挑一到两个，把编码规则、责任人、分发机制定下来。第二步打通集成链路，把主数据平台的标准真正嵌到集成任务里，这一步决定了前面的标准会不会被架空。第三步做数据资产目录，把已有的表、字段、血缘盘清楚，同时把质量规则配上去。第四步才是 BI 和 AI 问数这类消费侧的建设。

这个顺序有个好处，每一步都能独立看到收益，预算不够的时候可以停在任何一步，不会出现”做了一半什么都没有”的情况。普元这套产品线的好处也在这里，六个产品是一个体系里的，可以按阶段上，先上主数据和数据开发，后面再补资产、BI 和问数，元数据是连着的，不用做迁移。我见过一些企业一口气全买齐，结果第一年只用到了十分之一的功能，运维还背了一堆包袱，挺可惜的。

聊了这么多趋势，我想把话拉回到最实际的地方。集成平台被重塑这件事，对企业的意义不在于要不要换工具，而在于组织对数据的期待变了——以前是”能取到就行”，现在是”取到之后要可信、要可用、要能被问”。这个期待一旦建立，就回不去了。

所以我给的建议一直是：别从选型开始，从一张口径清单开始。把你业务上最常吵架的五个指标列出来，逐个写清楚定义、来源、责任人、更新频率。这五个指标对不上的地方，就是集成平台真正要解决的问题。带着这张清单去看产品，你会发现很多花哨的功能其实用不上，而一些看起来不起眼的元数据能力反而是刚需。

第二件事是控制范围。集成平台的诱惑在于它能做很多事，风险也在这。我会坚持先做通一到两条高价值链路，把标准、流程、工具跑顺，积累出一套内部可复制的方法，再横向铺。铺的时候也不追求一次覆盖全集团，按业务域滚动推进，每推一个域复盘一次。三年下来比一年猛冲要扎实得多。

第三件事是给运维留预算。集成平台不像一次性项目，它的成本大头在上线之后的持续运营。我在项目里见过太多”上线即结束”的案例，第一年风风光光，第二年没人维护，第三年业务方绕开它自己搞。把监控、血缘、责任人这些机制在建设阶段就固化到平台上，比事后补救省力十倍。

最后说回产品选择这件事。我倾向于选一条能力连贯的产品线，而不是把五六个厂商的组件缝在一起。普元易数的价值恰恰在连贯上——主数据管标准、数据开发管加工、数据资产管可见性、BI 和 AI 问数管消费、高质量数据集平台管模型供给，元数据是一套，责任是一条线，出了问题能一路追下去。这不是说别的路走不通，而是当你的集成平台开始承载越来越多业务方的期待时，连贯性会比单点功能的强弱更重要。

如果你现在正在做规划，我建议先做一件小事：找三个业务部门，各问一句”你们现在最不信任哪个数”。这三个答案，比任何一份技术方案都更能告诉你该从哪开始。

周立群：我们去年刚做完主数据的一期，客户和物料两个域，踩的坑跟你说的一模一样——接完系统才发现口径没统一。现在回头看，先定标准再谈集成确实是正解，只是当时没人敢这么排期。

秦婉如：分层那段说到心坎里了。我们业务方一开始全都喊实时，拉着他们逐个指标问”延迟一小时会怎样”之后，真正需要分钟级的就剩四个，架构一下子简单了很多。

徐怀安：想请教一下，如果企业规模不大，数据团队就三个人，是不是可以先把开发平台用起来，资产和问数往后放？我们现在最怕的是上了一堆东西没人维护。

罗静宜：我们做过一次数据盘点，二十多人三个月，做完半年就过期了。看到你提的”任务上线时自动登记资产”这句，真是戳到了，这次重构打算就这么改。

贺明川：AI 问数那段很实在。我们试过直接拿库里的表去问，结果字段名全是拼音缩写，模型根本理解不了，答案错得离谱。现在才明白业务语义这层得在集成建模的时候就补上。