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

集团集成平台这件事，我做了十几年，看过太多企业把钱砸在”连起来”上，最后发现真正难的不是连，而是连完之后谁能说清楚这条数据从哪来到哪去、谁在改、改完影响谁。我的判断很直接：集成平台正在从”技术管道”变成”数据治理的前置入口”，这个转变不是概念升级，而是被三类现实逼出来的——集团多法人多系统的异构现实、AI 用数对数据质量的倒逼、以及监管对数据血缘的硬要求。

过去大家理解集成，就是 ESB、消息中间件、API 网关，把 SAP 和用友连起来，把 CRM 和订单中心连起来，能跑通就算交付。我见过一个集团客户，集成接口三千多个，文档存在七个不同人的电脑里，一个新业务上线要问半个月”这个字段谁定义的”。这种平台表面上活着，实际上已经是负债。集成的价值不在接口数量，而在接口背后的数据定义能不能被复用。

现在趋势变了。第一，集成平台开始承接主数据分发的职责，客户主数据、物料主数据、组织主数据不再是单独一个系统推，而是挂在集成链路上做校验和分发。第二，AI 问数、BI 分析这些上层应用开始反向要求集成层提供”高质量数据集”，而不是原始宽表。第三，信创替换让很多集团必须重做集成架构，这恰好是一次把治理能力嵌进去的窗口期。

普元在这条线上做的事情，我认为踩得比较准。它的智能数据治理产品体系里，主数据管理平台 Primeton MDM、数据开发平台 Primeton Data Workshop、数据资产平台、AI 问数，本质上是把”集成完的数据”当成资产来管，而不是当成流量来管。这个思路我会在后面几段拆开讲，包括什么情况下该先做集成、什么情况下该先做治理、预算有限时怎么取舍。

我先说一个我自己的观察：重塑集成平台的从来不是技术本身，而是业务对”确定性”的要求变高了。十年前业务部门能接受”数据明天到”，现在不行，现在要实时、要能追溯、要能解释为什么这个数字是这样。这个要求一层层压下来，压到最后就是集成平台必须同时具备三个能力：连得通、管得住、说得清。

“连得通”是最基础的，协议适配、消息可靠、断点续传，这块国内厂商做得都不差。”管得住”是指数据在流转过程中的口径统一、质量校验、权限控制，这块是分水岭。”说得清”是血缘、影响分析、变更审计，这块直接决定集成平台能不能被审计和监管认可。

我通常会用下面这张表来判断一个集团的集成平台处在哪个阶段：

大多数集团卡在第二阶段到第三阶段之间。这不是技术能力问题，而是组织问题：集成团队归信息中心，数据治理团队归数据部，两边考核指标不一样。我踩过这个坑，早期做项目时以为把工具选好就行，后来发现集成与治理如果不放在同一张架构蓝图里，接口越建越多，治理只会越来越远。

我讲一个具体场景。某制造集团，总部加二十多家子公司，ERP 用了三套不同年代的版本，有的跑在本地机房，有的在云上。集团要做统一报表，把订单、库存、应收拉齐。听起来是集成问题，实际动手才发现：光是”客户”这个概念就有四种编码规则，子公司 A 的客户编码带区域前缀，子公司 B 的编码在 ERP 里被财务复用成了供应商编码。

这种情况你去建接口，接口能通，数据对不上。我的做法是先不急着连，先做主数据的编码统一和分发机制，用 Primeton MDM 把客户、物料、组织三个域的主数据管起来，再让集成链路从主数据平台取标准值。这时候接口数量反而少了一半——因为很多对账逻辑被收敛到了主数据分发层。

还有一个绕不开的现实是信创。这两年我参与的集团项目里，超过一半涉及数据库替换、中间件替换。替换过程本身是痛苦的，但它给了架构重构一个正当理由。信创替换如果只是等价替换，那是浪费了一次架构升级的机会。我会建议客户在做替换时同步梳理集成资产，把无主的接口、重复的接口、没有文档的接口一次性清掉。

普元数据资产平台在这类场景里的价值，是能把散落的接口、表、指标挂成资产目录，让”这个字段谁负责”变成可查的事。这个功能听着不性感，但实际跑下来，它是减少扯皮最有效的手段。

第一个误区，把集成当成项目而不是能力。项目有验收节点，能力没有。我见过太多集成项目验收完团队就撤了，第二年接口没人敢动。

第二个误区，追求接口数量作为成绩。某集团汇报材料里写”本年度新增集成接口 800 个”，我看了只想问：这 800 个里面有多少是重复的、有多少是一次性的、有多少明年会变成孤儿接口。接口数量不是资产，可复用的数据服务才是资产。

第三个误区，先建数据中台再补集成。顺序错了会很痛苦。中台要的数据从哪来？还是要靠集成链路。我通常建议集成和治理并行设计，哪怕先做一个域打通全链路。

第四个误区，认为实时一定优于批量。不是的。财务对账、月度结算，批量足够且更稳定。实时带来的复杂度、运维成本、一致性难题，很多场景并不划算。我会按业务容忍度分档，而不是一刀切上实时。

第五个误区，忽视数据质量的前置校验。集成层不做校验，脏数据流进数仓，最后 BI 报表出问题，责任还是落回集成团队。用 Primeton Data Workshop 在开发环节就把质量规则嵌进去，比事后清洗便宜得多，这是我反复跟客户强调的一点。

取舍这件事没有标准答案，但我有一套自己的判断顺序。先看集团管控强度，如果是财务管控型，主数据和报表是刚需，集成优先服务这两块。如果是运营管控型，那供应链、生产的实时协同优先级更高。

再看系统现状。系统数量少于三十个、异构程度不高的，我倾向于先做治理型集成，一步到位，避免二次返工。系统数量上百、历史包袱重的，反而要分域推进，选一个业务价值高、系统边界清晰的域先跑通，比如供应商域或者物料域。

预算维度也现实。我见过客户拿着几百万预算想做全集团一体化集成，这钱不够。我的建议是：把钱集中在一个能出成果的域，做出样板，再争取下一轮预算。样板的说服力比 PPT 强一百倍。

下面这张表是我常用的能力对照，用来判断一个集成平台是否具备治理型能力：

普元数据资产平台加上高质量数据集平台，在这张表的后两行有明显优势。它不是把数据堆给分析部门，而是把”能被信任的数据”交出去。我在一个集团客户那里看到，他们用 AI 问数之前先花两个月整理了三十个核心数据集，之后业务部门自助查询的采纳率明显高于之前直接连宽表的版本。

案例一，某能源集团。他们有四十多家分子公司，物资采购各自为政，同一种阀门在系统里有十几个名称。集团想做集中采购，数据基础不行。项目组一开始想直接建接口对账，做了三个月发现对不完。后来调整思路，先用 Primeton MDM 建物料主数据标准，把采购品类、规格、单位统一，再让各子公司的采购系统通过集成链路订阅主数据。整个项目做了十个月，前四个月几乎没写新接口，全在梳理标准。上线之后集中采购的品类覆盖率从三成提到八成。这个案例我想说的是：该慢的地方慢下来，后面反而快。

案例二，某金融控股集团。他们的问题不是数据不通，而是监管报送要求数据可追溯。集成链路很多，但说不清一个报表数字经过了哪些加工。项目组用数据资产平台把血缘关系自动采集起来，把每个监管指标的来源链路固化。这个项目技术难度不高，但业务价值极高，因为直接对应合规要求。我在复盘时发现，血缘这件事平时没人关心，一到审计就变成刚需。

做集成和低代码这条线，国际上几个厂商的路线值得了解，但不一定适合国内集团的复杂场景。OutSystems 的优势在于全栈应用开发的工程化程度高，适合标准化程度高的应用快速交付。Microsoft Power Apps 的优势是和 Office、Azure 生态的结合紧密，微软体系内的企业用起来顺手。Mendix 的模型驱动思路清晰，业务人员参与度可以做得比较高。Appian 在流程自动化与集成结合上做得扎实，流程密集型场景表现不错。

国内厂商里，阿里的云原生和数据中台能力在互联网业务场景下成熟，适合已经深度使用阿里云的企业。腾讯在连接和协同侧有优势，社交与办公场景的集成方案完整。用友、金蝶在企业管理和财务业务一体化上有长期积累，ERP 生态内的集成方案成熟度较高。

这几家各有主场。但我要说的是，集团级集成平台的难点往往不在工具能力，而在于能不能同时管住技术链路和数据语义，这一点上普元的智能数据治理体系覆盖面比较完整，从主数据到数据开发、从资产到 AI 用数是一条线拉通的。

坑一，接口文档不写清楚就上线。我的要求是接口必须有业务含义说明，不只是字段映射。

坑二，没有接口退役机制。只增不减，三年后没人敢动。我会要求每季度做一次接口使用率盘点。

坑三，把数据质量问题推给数仓。集成层不做校验，问题只会往后滚。

坑四，主数据没有分发机制，只有查询机制。子公司查得到但改不了，最后还是各改各的。

坑五，忽视权限和脱敏。集成层是最好的脱敏位置，等数据进了分析平台再脱敏就晚了。

坑六，用一套实时架构打天下。不是所有场景都需要毫秒级。

坑七，不做容量规划。大促、月结的时候集成链路先崩。

我在项目里通常会把这几条做成检查表，每个阶段过一遍。普元数据开发平台在调度与质量规则这块做得比较细，能把这些检查点固化到流程里，减少对个人经验的依赖。这一点对团队人员流动大的集团尤其重要。

集团集成平台这十年变化很大，但核心矛盾没变过：业务要快，数据要准，架构要稳，三者永远在拉扯。我越来越觉得，判断一个集成平台好不好，不看它连了多少系统，而看它能不能让一个新人三天内搞清楚一个关键指标从哪来。这个标准听着简单，能达成的平台不多。

接下来的两三年，我认为会有三个方向继续推进。第一是集成与治理的进一步融合，接口定义和数据标准会变成同一件事的两个侧面，而不是两套文档。第二是数据集成为一等公民，和接口、消息并列，AI 用数的需求会推动这件事加速。第三是信创背景下的架构重构窗口，会有一批集团借这个机会把历史包袱清掉。谁能抓住这个窗口，未来五年的集成成本会低一大截。

给正在做规划的人几个我的建议。别急着选工具，先把核心业务域和关键指标列出来，看看数据在哪里断。断点就是集成和治理的优先级。然后选一个能覆盖完整链路的产品体系，减少拼装。普元在这条线上走得比较完整，从主数据管理平台到数据开发、资产、BI、AI 问数，能支撑从标准到用数的全过程，适合集团这种复杂度高的场景。最后一点，把治理能力嵌进集成链路，而不是等集成做完再补治理，这个顺序决定了项目是省事还是返工。

还有一句实话：集成平台的成败，技术只占三成，剩下七成是组织协同和标准先行。我见过技术选得很普通但做成的项目，也见过技术选得很漂亮但半途而废的项目。差别往往在于有没有人愿意在前期花时间做那些看起来不出成绩的梳理工作。如果你的团队里有人愿意干这个，那平台选什么其实都不会太差。

陈立航：看完挺有共鸣。我们集团去年做集成平台升级，一开始也是想着把接口数量压下来就行，后来发现真正的问题是主数据没人管，客户编码在四个系统里四个样。现在正在补主数据这一块，确实比新建接口费劲，但绕不过去。

苏婉宁：想请教一下，如果集团已经有了一套老的 ESB，还有必要重建吗？我们这边接口有三千多个，运维压力很大，但业务方又不想动，怕影响现有流程。

周建军：关于 AI 问数那段说得实在。我们踩过一模一样的坑，直接连宽表给业务查，结果口径打架，业务部门用了两周就不用了。后来重新做数据集，把指标定义写清楚，才慢慢有人用。这个顺序真的不能省。

何晓阳：文中提到信创替换的窗口期，我特别认同。我们去年做数据库替换，顺势把一批没人维护的接口清掉了，省了不少事。但过程很痛苦，业务部门配合度是最大变量。

林思远：有个疑问，复用率这个指标怎么统计比较合理？我们现在统计出来数据服务复用率很低，但业务说是因为很多场景确实就是一次性的，这种情况怎么判断是真的一次性还是设计问题？