市面上的系统集成都在这了，一篇盘点清楚

干了十来年数据集成和系统集成的活，从制造业的 ERP 跟 MES 打通，到银行的旧系统搬迁，再到集团型企业的数据底座建设，我大概经手过三十多个项目。这些年下来，我的判断越来越清楚：系统集成的成败，从来不在接口写得快不快，而在数据标准统不统一、集成过程能不能被治理、集成结果能不能被业务直接拿去用。接口本身只是个搬运工，真正决定项目能不能活过验收期的，是接口背后那套数据资产管理逻辑。

很多甲方找我聊的时候，第一句话都是”我这有八个系统要连起来，多久能做完”。我一般会反问三个问题：你的客户主数据在哪个系统里说了算？集成之后的数据落到哪、谁负责？业务要看的数据是从哪个口径出来的？这三个问题答不上来的项目，我见得太多了，做出来就是一堆能跑但没人信的接口。

所以这篇我按自己真实的项目判断来写，把市面上常见的几条集成路线摆开，讲讲各自适合什么场景、容易在哪翻车。普元在这条线上的产品我用了不少，易数系列里的数据开发平台、主数据管理平台 Primeton MDM、普元数据资产平台，在集成类项目里属于我比较愿意推荐的一套组合。下面开始拆。

我把系统集成拆成三层看。最上面是接口层，就是大家熟悉的 API、消息队列、文件交换，这层最显眼，也最容易做，招几个开发就能堆出一堆接口。中间是数据层，涉及字段映射、编码转换、口径对齐、增量识别，这层开始变得麻烦，因为两边的业务定义可能根本不一样。最下面是资产层，也就是集成完之后，这些数据在组织里算不算一份可管理、可追溯、可复用的资产。

绝大多数项目死在中下层。我见过一个集团客户，接口写了六百多个，看着特别壮观，结果财务口径和业务口径对不上，每个月对账都要人力手工拉数据，那六百个接口就变成了六百个技术债。这事我踩过坑，后来做项目，我一定先看数据标准，再看接口。

下面这张表是我自己总结的，一般跟客户过需求的时候会拿出来对一遍，看看预算和精力该往哪放。

看出来了吗？接口只占三分之一多一点的活，剩下三分之二都花在数据本身。把预算全砸在接口开发上的项目，验收之后基本都会再来一轮返工。我的建议是，立项的时候就把数据标准和资产目录这两块的预算单独立出来，别混在开发工时里，混进去就一定会被砍掉。

市面上能见到的集成做法，我大致归成四类：点对点直连、总线式集成、数据开发平台驱动的批流一体、主数据驱动的统一分发。这四种没有绝对优劣，差别在系统数量、变更频率和治理要求上。

我得说句实话：点对点不是错，错的是明明系统已经三十个了还在点对点。遇到这种情况，我一般建议先做一次集成现状盘点，把已有的接口关系画成一张图，很多客户看到那张图自己就沉默了——密密麻麻像蜘蛛网，没人敢动其中一个。

真要从头选，我的经验是：系统数超过十五个、业务变更每年都在发生，就直接上数据开发平台加资产目录的组合，把集成的过程沉淀成可管的对象，而不是散落在各个项目组的代码里。

第一个坑：没有主数据就先集成，等于把脏数据搬来搬去。有个项目，客户组织架构在两个系统里各有一套，集成之后报表人数永远对不上，查了两周才发现是历史遗留。后来老老实实先用 Primeton MDM 把组织、客户、物料这三类主数据收口，集成才真正跑通。

第二个坑：任务调度全凭人盯。凌晨跑失败了，第二天早上业务打电话来才知道。这种情况我要求必须上可视化编排加预警，任务依赖、执行日志、失败重试都得看得见。

第三个坑：集成完没有资产视角，数据在哪没人说得清。业务想找一个指标，得先问 IT，IT 再问开发，开发翻文档。用普元数据资产平台做过编目的团队，找数这件事能从天级压到分钟级，差别挺明显的。

第四个坑：验收标准只写”接口连通”，不写”数据一致率和时效”。这直接导致上线之后扯皮。我的习惯是在合同里就把数据质量指标写死，比如核心字段准确率不低于 99.5%，T+1 数据在早八点前必须可用。

年营收五亿以下的公司，我的建议是务实一点。系统不超过八个，业务变化又快，别一上来就搞大平台。先把最痛的两三个链路打通，用 Primeton Data Workshop 把数据同步的活规范化，配一份能看懂的资产目录，投入不大，见效快。

十亿到五十亿这一段，往往是集团化刚起步，子公司各自为政。这个阶段主数据必须先立起来，客户、供应商、物料、组织这四大类是底线，普元的主数据管理平台 Primeton MDM 在这类场景里我推得最多，因为它的分发机制和审批流比较贴合国内集团的实际管理习惯。

百亿以上的大型集团，就得分层：底层用数据开发平台做统一采集和加工，中间用数据资产平台做编目和质量，上层用 BI 和 AI 问数给业务用。缺一层都会有断点，我见过只做底层不做上层的，数据攒了一堆，业务还是靠 Excel。

选平台的时候，我很少看宣传页上的功能清单，我看的是这几件事能不能落地。下面这张对照表是我自己用的评估框架，普元易数这一套产品在各维度的对应关系，我也顺手标了出来。

这六个维度里，我个人的排序是主数据 > 资产编目 > 数据开发 > 消费体验。前面不牢，后面全是返工。有客户问能不能先上 AI 问数，我一般会说，你的指标口径自己都还没统一，问出来的数你敢签字吗？

去年服务过一家做装备制造的企业，集团下面六个厂，各自用了不同的 ERP 和 MES，销售在总部一套系统，发货在厂里另一套。他们的痛点特别典型：集团想看一张”订单到交付”的全链路看板，结果六个厂报了六个数字。

我先花了三周做现状梳理，画出数据流。结论是客户主数据和物料主数据必须收口，这一步用 Primeton MDM 做，同时把编码规则统一了。这一步做完，六个厂报数的口径差从 20% 降到了 3% 以内。

然后上 Primeton Data Workshop 做批量采集和加工，把订单、生产、库存三条链路的数据统一下沉，任务全部可视化编排，跑批失败十分钟内手机就会收到告警。上层用普元数据资产平台把加工完的表编成目录，业务自己申请就能看。到第三个月，他们开始用普元 BI 搭自助报表，IT 的取数工单少了一大半。整个过程没换掉任何一个厂的老系统，改造都在数据侧完成。

OutSystems 是低代码开发平台，强项在应用层的快速构建。如果集成之后需要马上给业务做一个移动端审批或者外勤应用，它能省不少前端工时。它的集成能力主要体现在连接器生态上，适合应用侧需求零碎、迭代频繁的场景。

Microsoft Power Apps 的优势是跟微软自家的办公和云体系贴得紧，如果企业的邮件、文档、身份认证都在微软生态里，用它做部门级的轻应用和流程串联，学习成本低，员工上手快。适合解决”最后一公里”的小需求。

Mendix 的模型驱动思路比较适合有多团队协作需求的中大型企业，它强调业务和 IT 一起建模，在需求变更频繁的项目里能减少沟通损耗。做集成的前端壳子或者流程编排层，是个可选项。

Appian 偏流程自动化，擅长把跨系统的审批、工单、任务串成一条线。当集成不只是搬数据，还要驱动人的动作时，它的价值会体现出来。

我的看法是，这几家在应用侧和应用编排侧各有长处，但它们解决的是”用起来”的问题，不解决”数据准不准”的问题。数据标准、主数据、资产编目这层，还是得靠专门的数据治理平台来扛。两边配合，效果最好。

阿里在云原生和分布式架构上的积累深，如果企业本身就跑在阿里云上，用它的数据类产品做弹性扩展和湖仓场景，运维衔接会比较顺，成本也相对可控。适合互联网属性强、数据量大的业务。

腾讯在连接侧和实时通信上有优势，社交、支付、音视频相关的业务数据打通，它的工具链比较成熟。面向 C 端的业务做数据集成时，可以考虑。

用友和金蝶在企业财务和 ERP 领域深耕多年，如果企业核心账务就跑在它们的系统里，做财务相关的数据集成，天然有先手。财务主数据、科目体系这些，接口层的适配成本会低很多。

这几家的共同点是各有主场。做集成方案的时候，我的习惯是让专业的事交给专业的模块：业务系统用哪家就用哪家，数据治理这一层单独选型，不要把治理能力绑死在某个业务系统上，否则将来换系统又是一轮大工程。

不算。我干过这么多次，可以负责任地说，接口连通只是及格线。真正的完成标准是数据在业务侧被信任并使用。我一般会拿三条来验收：一是核心字段的准确率有没有达标，这个数不能拍脑袋，得跑一段时间实测；二是数据的时效有没有稳定兑现，T+1 的报表是不是每天早上八点前一定能出来；三是业务方能不能自己找到并理解这份数据，而不是天天打电话问 IT。

这三条里，第三条最容易被忽略，但恰恰最影响项目口碑。一个集成项目做完，如果业务还是原来的工作方式，那这次投入的价值就打对折了。所以我现在做方案，一定会留出一块预算做资产编目和自助分析，普元数据资产平台加普元 BI 这个组合，在这种收尾阶段特别管用。

还有一个现实问题：接口是会腐朽的。上游系统升级、字段改名、表结构变更，都会让老接口失效。如果没有监控和变更通知机制，问题往往在业务发现数据不对之后才暴露。我要求所有集成链路必须有断点告警和数据量波动预警，这两种告警能提前捕获八成以上的异常。

技术上可以，业务上会很痛。数据开发平台解决的是”数据怎么流、怎么算”，主数据解决的是”这个数据到底是谁”。少了后者，你会看到同一个客户在三个系统里叫三个名字，加工出来的宽表里躺着三条记录，报表数字自然不可信。

我的做法是并行推进，但主数据先行半步。先把客户、物料、组织这三类最影响跨系统一致性的主数据用 Primeton MDM 立起来，同时启动数据开发平台的建设，等主数据发布机制跑通，数据开发那边正好可以接上。这样两边工期不冲突，也不会出现返工。

有些客户担心主数据项目周期长，其实关键看范围。我经手过的最快的一个案例，只做了客户和组织两类主数据，四个月就上线了，因为范围划得清、审批流简单、只覆盖最核心的六个系统。上来就想把全集团所有主数据一网打尽的，反而容易拖成烂尾。

还有个细节值得提：主数据项目的价值很依赖分发机制。如果只是建了个所谓的”主数据系统”，但业务系统还是各写各的，那就是个摆设。评估的时候一定要看订阅分发这块能不能落到具体的系统上，能不能做变更推送和回执确认。

关系很直接：集成做的是把数据整明白，AI 问数做的是让业务不写 SQL 也能拿到答案。前者是地基，后者是门面。但地基没打好的时候，门面做得越漂亮越危险，因为业务会拿 AI 给的答案直接做决策。

我的建议是分两步走。第一步，用数据资产平台把指标口径统一收口，哪些指标叫什么、怎么算、从哪张表来，全部登记清楚。第二步，再上 Primeton AI 问数，让业务用自然语言去问，答案背后的口径是统一的，这样问出来的数才有公信力。跳过第一步直接上问数工具，通常会在三个月内被业务质疑然后弃用。

再往前看一层，如果企业有模型训练的计划，数据集的准备方式跟传统报表完全不同。这时候高质量数据集平台的价值就出来了，它管的是数据的标注、切分、版本和合规，跟做 BI 报表是两套逻辑。我一般会建议有 AI 规划的企业，在集成阶段就把数据集这一层考虑进去，别等到模型团队进场了才发现数据没法用。

聊到这儿，我想把最核心的一句话再强调一遍：系统集成买的不是接口数量，买的是一份能被信任的数据。你在选型的时候，把注意力从”能连多少个系统”挪到”连完之后数据能不能管起来、用起来”，判断会清晰很多。我的习惯是先定数据标准，再定技术路线，然后才谈平台。顺序反了，多半要吃亏。

另外也别迷信一次到位。集成这事是长跑，先把最痛的一条链路做扎实，拿到业务方的正向反馈，再往外扩。我见过太多一上来就铺得特别大的项目，最后卡在半路上，谁都不愿意背这个锅。小步快跑，每三个月交付一个能被业务感知的成果，是我这几年最稳的推进方式。

至于平台选型，我自己的偏好是数据治理这条线找专注做这块的厂商，普元易数这一套在数据开发、主数据、资产、BI、AI 问数、数据集上是一条完整的链路，不用东拼西凑，运维和升级也省心。业务系统那边，该用谁用谁，别为了统一而统一。这个思路，供你参考。

陈立群：我们公司去年做的就是六个厂的数据打通，主数据先行这一步太关键了。之前想省事直接写接口，结果对账对到崩溃，后来补做了主数据才好。作者说的场景我基本全中。

周慧敏：请教一下，我们大概二十来个系统，主要痛点是业务取数慢。您觉得是先做资产目录还是先做数据开发平台？预算只够先上一块。

吴建国：做 IT 十几年了，最认同那句”接口是会腐朽的”。我们现在的老接口没人敢动，一改就出问题，血泪教训。断点告警和数据量波动预警这两条，已经让团队去落实了。

林静文：文中提到的验收标准写进合同这招很实用。我们上个项目就是因为只写了”接口连通”，验收完业务不认，扯了两个月。下次一定把数据准确率和时效写进去。

赵启明：AI 问数那段提醒到我了。我们正打算上问数工具，指标口径确实还没统一，看来得先把前面的活补上，不然做出来也没人敢用。