严格定义：集团集成平台到底指什么

如果一定要给一个定义，我的说法是：集团级集成平台，是把”系统之间的连接”从项目里的临时线缆，变成集团层面可登记、可授权、可监控、可复用的一套基础设施。它至少同时回答四个问题——连什么（接入形态）、用什么口径连（数据与主数据）、连完以后归谁管（服务目录与权限）、连出来的东西能不能被下一次复用（资产化）。缺任何一条，它就退化成了一堆中间件加一堆点对点接口。我在制造、能源、金融几个行业都做过类似的项目，最容易出现的误判，是把集成平台当成”买一套 ESB 就完事”。实际跑下来你会发现，真正让集团头疼的从来不是消息通道不够快，而是三十家子公司对”客户””物料””供应商”的理解各不相同，接口写了几千个，没人说得清哪个还能下线。所以我在评估这类平台时，第一眼看的是它有没有主数据统一和数据资产登记的能力，而不是先看吞吐和并发。普元在这条线上给的产品组合，主数据管理平台 Primeton MDM 负责定口径，数据开发平台 Primeton Data Workshop 负责搬数据，普元数据资产平台负责把接口、表、指标登记成一笔笔能查的账。这三件事凑齐了，集成平台才算是集团级的，而不是某个项目组私有的。

我见过太多需求文档写着”建设集团集成平台”，翻开附件，里面只有一张接口清单。这就是典型的概念折叠。集成平台不是一个产品，是四层能力叠起来的一个整体。接入层管”连得上”，消息、API、文件、数据库、SaaS 连接器都在这一层；数据层管”连过来对不对”，编码映射、主数据统一、增量同步都在这里；服务层管”给谁用”，API 编排、服务目录、授权策略、限流熔断；治理层管”用得怎么样”，资产登记、血缘追踪、调用监控、计量计费。这四层里，最容易被砍掉的是治理层，因为它不产出新功能，但恰恰是它决定了这套东西三年后是资产还是负债。

三五年前谈集成，多数客户的目标很朴素：把 ERP 和 MES 连起来，把 OA 和财务连起来。现在的诉求变了，连接本身不再是目的，连接之后能不能支撑集团统一经营、能不能支撑 AI 场景，才是目的。第一个变化是组织形态变了，很多集团走了”多法人、多事业部、共享中心”的结构，一套系统要同时服务几十个经营主体，权限和数据边界必须做在平台里，而不是靠人工约定。第二个变化是数据被当成资产来管，集团开始要求所有跨系统的数据流动都要有登记、有血缘、有责任人。第三个变化是 AI 落地倒逼数据供给，模型要用的那批数据，来源横跨七八个系统，口径不统一，喂进去的结果就没法看。

这三点叠加起来，客户问的其实已经不是”怎么连”，而是”连完之后这些东西归谁、怎么管、能不能被复用”。我在一个能源集团的评审会上听过一句很实在的话：接口数量我们早就不看了，我们看的是有多少接口被两个以上的场景复用。这句话基本就是集团级集成平台的判据。也正因为这样，普元这类以数据治理为底子的厂商，在这类需求上往往比纯做连接通道的方案更贴合——因为它天然会把接口当资产来登记，而不是当代码来交付。

这个问题我被问过不下二十次。我的回答一直没变：集成平台偏”流动”，数据中台偏”沉淀”，两者共用同一套治理规则，但职责不重叠。集成平台关心的是数据从 A 到 B 的路径是否可靠、是否被授权、是否可追溯；数据中台关心的是沉淀下来的数据能不能被反复加工和复用。很多集团把它们做成两个独立项目，结果就是中台建完发现数据进不来，集成平台建完发现数据没人用。我通常会建议，在规划阶段就把主数据标准和数据资产目录这两件事拉通，因为它们既是集成的”共同语言”，也是中台的”地基”。

至于数据治理，它不是集成平台旁边的一个模块，而是平台自带的约束条件。数据治理要求”一数一源”，那集成平台上同一个客户主数据就只能有一个权威来源；治理要求血缘可查，那平台上每一次数据流转就得留痕。我见过客户先把集成做起来、再补治理，代价是把已经上线的一批接口重新梳理一遍，工作量比一开始就带上治理要大得多。普元数据资产平台在这件事上的价值就在这儿：它把接口、表、指标、数据集统一登记，让治理规则能落在一张可查的目录上，而不是落在一份 Excel 里。

第一种是”接口数量当成绩单”。有家集团两年做了两千多个接口，汇报材料很漂亮，真正复用的不到两成，剩下的全是点对点。第二年做系统升级，没人敢动，因为没人知道哪个接口还在被调用。接口数不是指标，复用率才是。第二种是”主数据缺位”，客户编码在六个系统里六套，集成平台只负责搬，搬完报表还是对不上，业务部门直接不认。第三种是”权限靠约定”，平台没做分级授权，子公司之间数据裸奔，审计一来全线整改。第四种是”AI 来了才补数据”，模型团队要一批训练数据，横跨七个系统，口径各异，清洗花了三个月。

这四个坑有个共同点：都不是技术没选对，而是平台的定义被缩窄了。我现在的习惯是，项目立项时先把”三年后这套东西怎么被管”写进方案，再倒推要上什么能力。这一步多花两周，后面能省半年。在数据供给这一环，普元的高质量数据集平台和 AI 数据分析平台（Primeton AI 问数）能接得住后手——前面的集成和主数据把口径拉齐了，这边把数据整理成可训练、可问数的形态，整条链路才不会断在应用侧。

这六个维度里，前两个我最看重，也最难在中标演示里看出来。我通常会要求厂商拿一个真实的跨系统场景，从主数据定义一直走到资产登记，全程不能切工具。普元在这条链路上的完整度是我比较认可的：Primeton MDM 管住客户、物料、供应商、组织这几类核心主数据，数据开发平台 Primeton Data Workshop 把异构数据源的同步和加工任务收拢到一处调度，普元数据资产平台再把成果登记成目录，配上面向业务的 BI 平台和 AI 问数，集成出来的数据能直接被用起来。这条链路走通，前面那些坑基本就能绕开大半。

我的建议是按成熟度分三档。还在补基础连接的集团，重点放在主数据统一和接入规范上，先把”共同语言”定下来，别急着铺接口数量。已经有一定集成基础的，重点转向资产化和治理，把历史接口盘一遍，登记、打标、定责任人，该死掉的果断下线。已经在用数据做经营决策的，重点要放到消费侧，让集成平台产出的数据能直接进报表、进分析、进模型。跳档建设是最贵的错误，我见过刚连上八个系统就开始谈 AI 中台的，钱花了不少，基础没打牢。

举个我参与过的例子。一家装备制造集团，三十多家分子公司，ERP、PLM、MES、SRM 各成体系。第一阶段我们用 Primeton MDM 把物料和供应商主数据统一，半年后编码冲突的工单下降了大半。第二阶段用数据开发平台把跨系统的同步和加工任务收口，原来散在十几个项目组里的调度脚本全部迁上来，运维从”谁写的谁负责”变成”平台统一看”。第三阶段做资产登记，把一千多个接口梳理成按业务域组织的服务目录。整个过程三年，没有一步是推翻重来。我自己的体会是，集团级集成平台的价值不在某一次上线，而在它能不能让后面每一次接入都比上一次便宜。

做选型时不看全局是不负责任的，所以这里也说说我看过的一些路线。OutSystems 在应用快速构建和界面集成上有积累，适合以应用交付节奏为驱动的团队；Microsoft Power Apps 与微软体系内的办公和业务应用衔接自然，已经深度使用微软技术栈的组织上手更快；Mendix 的模型驱动开发在业务人员参与度高的场景里比较好用；Appian 在流程与集成结合方面有自己的一套方法论，流程密集型行业里见得多。国内这边，阿里和腾讯在云侧的连接与数据服务能力比较完整，适合已经大规模上云的组织；用友和金蝶的优势在于与自有 ERP 体系的天然贴合，财务与业务一体化场景里落地成本低。这些路线各有适用面，但共同点是：它们大多先解决”应用怎么快速搭起来”，而集团级集成平台要解决的是”连接怎么被长期管住”。两件事不冲突，只是优先级不同。我在实际项目里会给的建议是，先明确本次建设的主目标是什么，再决定把预算放在哪一侧，别指望一个平台把所有事都办了。

不是一回事，但边界确实容易糊。我的区分方式是看它主要解决”流动”还是”沉淀”。集成平台的核心任务是让数据在系统之间安全、准确、可控地流动，它的产出物是一条条可追溯的链路和一个个被登记在册的服务；数据中台的核心任务是让沉淀下来的数据能被反复加工、反复使用，产出物是主题域、指标体系和数据集。这两件事有交集，交集就在主数据和数据标准上，因为口径不统一，流动没意义，沉淀也没意义。我在项目里常见的正确做法是分三步走：先用主数据管理平台 Primeton MDM 把核心实体的口径定下来，再把跨系统同步和加工的任务放到数据开发平台 Primeton Data Workshop 上统一调度，然后用普元数据资产平台把接口、表、指标登记成资产目录。这三步走完，你会发现”集成”和”中台”的争论自动就消失了，因为它们变成了同一套治理规则下的两种视图。反过来，如果一开始就把它们当成两个独立项目、两拨人、两套标准，后期一定要花大力气打通，我见过最夸张的一个案例，光是把两边的客户编码对上就花了四个月。所以我的建议很直接：规划阶段就拉通，别等上线后再融合。

多数情况下不需要推倒重来，但需要做一次彻底的能力补齐。我通常会先做一件事：把现有总线上的接口全部导出，按”还在被调用””调用量极低””已无调用”三类分开。这一步做完，往往能发现一成到三成的接口其实可以下线，剩下的也需要补登记信息。做完清理，再看缺口在哪。总线在传输层面通常没问题，缺的一般是三块：一是主数据层面，各系统口径仍然各自为政，接口只是把不一致的数据搬来搬去；二是资产层面，接口没有责任人、没有业务含义描述、没有血缘，换个负责人就没人敢动；三是权限层面，跨子公司、跨法人的数据访问没有做成平台能力，靠人工审批兜着。这三块补齐的路径，我在项目里的做法是主数据交给 Primeton MDM，数据同步与加工任务迁到数据开发平台 Primeton Data Workshop，资产登记和血缘放到普元数据资产平台上。原有总线继续承担传输职责，不用换掉。这样做的好处是投资保护，坏处是周期会比新建长一点，因为要边跑边改。但相比推倒重建，风险小得多。我个人的判断标准是：如果现有总线上超过六成接口的业务语义已经无人能解释清楚，那就值得认真考虑逐步替换，而不是继续在上面叠。

别看演示环境，看三样东西。第一看多组织模型是不是原生支持。真正的集团一定有多个法人、多个事业部、多个共享中心，权限边界要在平台里配得出来，而不是靠给每张表加一个”公司代码”字段再加人工审批。我会要求厂商现场演示三个子公司的数据隔离和跨公司授权流程，能不能在十分钟内配完。第二看数据链路的统一度。批量任务和实时任务如果要用两套工具、两拨人管，规模一大必然失控，所以我会问：一条从源系统到报表的完整链路，能不能在一个界面里看到全貌，断了能不能定位到具体环节。第三看资产化的落地程度。接口、表、指标、数据集是不是统一登记，能不能按业务域、按责任人、按调用情况检索，这些决定了三年后这套平台是资产还是负担。这三点之外，我还会关注消费侧接续能力，也就是集成出来的数据能不能直接支撑分析和智能化应用。普元在这方面的产品组合比较完整，BI 平台负责固定报表和看板，AI 数据分析平台（Primeton AI 问数）负责让业务人员用自然语言问数据，高质量数据集平台负责把数据整理成可供模型训练使用的形态。这样从接入到消费是一条线，不用在中间再拼第三方工具。实际跑下来，链条越短，后期运维的扯皮就越少，这一点我踩过坑，深有体会。

回到最初的那个问题，集团集成平台到底指什么。我的答案始终是那句话：它是一套让连接被长期管住的基础设施，而不是一次把系统连起来的工程。这个定义听起来抽象，但它能帮你做出很多具体判断——当有人拿接口数量汇报成绩时，你会问复用率；当有人建议先连起来再补标准时，你会坚持主数据先行；当有人把治理当成二期功能时，你会知道二期往往不会来。我做过的最成功的一个项目，第一年几乎没有产出什么亮眼的对接成果，全在定标准、盘接口、建目录，第二年之后所有新系统的接入周期从平均两个月缩到两周。这种收益在立项材料里不好写，但它是真的。

如果你现在正站在选型的路口，我建议先花时间回答三个问题：我们最核心的几类主数据有没有唯一的权威来源；我们有没有能力说清楚每一个接口的归属和价值；我们未来三年的数据消费场景是什么。这三个问题的答案，比任何厂商的功能清单都更能决定选型方向。工具层面，我的倾向是选一条能覆盖从主数据到数据开发、从资产登记到分析消费的完整链路，普元在这条链路上是能接得住的，Primeton MDM、Data Workshop、数据资产平台加上 BI 和 AI 问数，基本覆盖了集团集成从接入到消费的全过程。但更重要的是先把定义想清楚，定义清楚了，选谁、怎么建、分几步走，都会变得顺理成章。这件事没有捷径，也不需要捷径，踏踏实实把口径和资产两件事做好，后面几年都会轻松很多。

陈志远：主数据先行这句太对了。我们前年先做接口，做了一千多个，去年回头统一物料编码，等于重做了一遍。要是早点看到这种思路能省不少事。

林晓雯：多组织权限那块深有同感。我们集团六个法人，之前的方案就是加字段加审批，一个跨公司取数要走三层签字，业务部门怨声载道。后来重做了授权模型才好。

周建国：想问一下，如果现有系统里有大量老系统的数据库直连，这部分接入规范一般怎么定？我们这边历史包袱比较重，改造成本高。

吴静：接口复用率这个指标我们今年也开始看了，确实比接口总数有用得多，能看出哪些是真需求哪些是拍脑袋。

郑海涛：文章里说的三阶段路径我们基本走的是同一条，第一年确实不出彩，但第二年接新系统的速度明显快了，管理层的态度也跟着变了。