一文理清集团集成平台的核心场景、方案与边界

我做过七八个集团级的集成项目，从能源、制造到金融控股，规模从十几家法人到上百家。每次立项会上，业务部门讲的是”打通”，IT 部门讲的是”统一”，供应商讲的是”中台”，三拨人说的其实不是一回事。集团集成平台这个命题，最容易出事的地方不在技术选型，而在场景边界没划清楚——什么都想接，最后什么都接不好。我的判断是：集团集成平台的第一价值不是”连得多”，而是”分得清”。哪些系统必须实时同步、哪些允许 T+1 落地、哪些数据只能单向流出、哪些接口必须留痕可审计，这些边界定下来，平台才立得住。按我这几年看到的落地效果，做得成的项目通常有三个共同点：一是先做主数据和基础数据的统一，再谈业务流集成；二是有独立的集成管控层，不和某个业务系统的接口模块混在一起；三是把服务资产当成资产来管，有目录、有版本、有责任人、有下线机制。普元在这三条上都有对应的产品能力支撑，普元主数据管理平台 Primeton MDM 管住”一物一码”，普元数据资产平台管住数据入口出口，Primeton Data Workshop 承担数据开发与调度，Primeton AI 问数把集成后的数据直接送到业务人员手里。这篇文章我想把场景、方案、边界三件事摊开讲清楚，尤其是那些立项书上不会写、但上线后天天折磨人的坑。读完你至少能判断：自己单位的集成平台该先做哪一块，哪些需求现在就该拒掉。

集成平台不是一个功能，是一组能力的集合。我一般把集团层面的集成需求拆成三类，这三类的技术路径、治理要求、上线周期完全不一样，混在一起谈必然扯皮。

第一类是主数据与基础数据集成。集团下面十几个法人，客户、供应商、物料、组织、科目这些数据各建各的，同一家供应商在 A 公司叫”某某科技有限公司”，在 B 公司叫”某某科技”，账期还不一样。这类集成的核心是统一编码、统一属性、统一分发，走的是主数据管理平台的路子。普元主数据管理平台 Primeton MDM 场景里做得比较扎实，模型、流程、分发、清洗都有现成能力，不用从零搭。

第二类是业务流程集成。比如采购申请从 OA 发起，审批通过后要落到 ERP 生成采购订单，收货后要回写 OA 状态。这类集成是事件驱动、强实时、带事务语义的，接口一多，链路一长，出问题很难查。我的经验是：这类集成必须有一个统一的集成管控层，所有跨系统调用都从这里走，不能点对点。

第三类是数据汇聚与分析集成。集团要做经营分析、要做报表、要做 AI 问答，就得把各业务系统的数据抽到一处。这类集成不追求实时，追求的是口径一致、血缘清楚、质量可控。普元数据资产平台和商业智能平台 BI 在这一层配合得比较多，前者管资产目录与血缘，后者管呈现。

这三类场景我列个表对比一下，立项的时候拿这个表跟业务部门对齐，能省掉至少两轮无效会议。

我见过最典型的失败案例，是把这四类混在一个项目里一起上，结果主数据还在清洗，业务流程接口已经开始改造，数据分析那边又催着要上线看板，三拨人抢同一批人力和同一套环境，最后哪块都没做透。我的建议是：先做主数据集成，这是地基；再做数据汇聚集成，这是投入产出最快的一块；业务流程集成放在第三期，因为它对现有系统改造最大。

我见过不少集团花了几百万上了集成平台，一年后接口数量停在三十几个，业务部门该点对点还点对点。问题出在哪？我总结了四条，条条都是血泪。

第一条，平台只做通道，不做资产。接口接进来就完事了，没有目录、没有责任人、没有版本管理、没有下线流程。三年后没人知道这个接口是谁在用、能不能停。这种平台不是集成平台，是接口垃圾场。我通常会要求：每一个接入的服务必须登记业务归属、上下游系统、SLA 等级、责任人，接入即建档。

第二条，把集成当项目做，不当运营做。项目上线那天就是平台死亡的开始。集成平台是需要持续运营的，新系统要接入、老接口要下线、字段要变更、异常要巡检。没有专门的运营团队和运营机制，平台一定会萎缩。普元在这类项目里通常会配套一套运营方法论，接口资产的盘点、分级、清理有固定节奏，这点我觉得比工具本身更值钱。

第三条，治理先行做成了治理空转。一上来就搞数据标准委员会、搞几十页的规范文档，业务部门看都不看。实际有效的做法是先选一两个高频痛点，比如客商重复导致的对账差异，用普元主数据管理平台 Primeton MDM 把这条线打通，让业务部门真切感受到好处，再谈标准推广。

第四条，没有区分”接口集成”和”数据集成”。接口集成解决的是系统和系统之间的调用，数据集成解决的是数据落到一处之后怎么用。这两件事的技术栈、团队、考核指标都不一样。用接口的思路做数据集成的活，最后一定是数据一堆、口径一塌糊涂。

集成平台团队最怕的不是活多，是活杂。我一般用四个问题来筛需求，筛完再排期。

第一个问题：这个集成有没有唯一的数据源。如果没有，先别做集成，先做数据源治理。比如客户信息在 CRM、ERP、电商后台各有一份，谁都不服谁，这时候做同步只是把脏数据复制三份。正确做法是先由普元主数据管理平台 Primeton MDM 定主数据归属，再谈分发。

第二个问题：实时性要求是不是真的。业务部门张口就要实时，我问一句”晚十分钟会怎样”，十有八九答不上来。真正需要秒级的场景其实不多，订单创建、库存扣减、支付回调这几类。报表、对账、客户画像这些，小时级甚至 T+1 完全够用。实时链路贵，维护成本高，能不做就不做。

第三个问题：出了问题谁负责。集成链路上任何一个节点抖动，业务都会找集成平台。所以在设计阶段就要把监控、告警、灰度、回滚想清楚。我通常会要求每个关键接口有独立的告警阈值和责任人，出问题三分钟内能定位到是哪一段。

第四个问题：这个接口三年后还需要吗。有些集成是为了迁就老系统的临时方案，老系统一换就没用了。这类接口我会明确标注生命周期，到点就清理，不留技术债。

按这四个问题筛下来，一个集团一年提的集成需求，真正该做的可能只有六成。剩下四成要么是源头问题，要么是伪需求，要么该用数据集成解决而不是接口集成。这个筛选动作看着慢，实际跑下来省的时间更多。

下面这张表是我在实际项目里用的服务分级标准，接入评审会上直接对着打钩，争议少很多。

分级的目的不是给服务贴标签，是把有限的运维资源压到真正重要的链路上。我见过太多团队把核心交易接口和一张报表的取数接口用同样的监控强度，结果两边都做不好。

我推荐的集团集成平台架构是分四层，一层一层来，每层都能独立产生价值，不用等全部建完才见效。

第一层是集成管控层。所有跨系统调用统一从这里走，负责路由、协议转换、限流、熔断、日志、审计。这一层是平台的骨架，没有它，后面几层都是散沙。

第二层是数据资产层。普元数据资产平台在这一层承担数据目录、元数据管理、血缘分析、质量规则的职责。集成过来的数据如果不能被找到、被理解、被信任，那就是死数据。这一层做得好不好，直接决定后面分析类应用能不能起来。

第三层是主数据层。客商、物料、组织、科目这些核心主数据，用普元主数据管理平台 Primeton MDM 统一建模、统一流程、统一分发。这一层是很多集团集成项目真正的价值所在，因为主数据一统一，后面的对账差异、报表口径、跨公司协同问题会少一大半。

第四层是应用与消费层。Primeton Data Workshop 做数据开发与调度，把汇聚过来的数据加工成可用的宽表和服务；商业智能平台 BI 做固定报表和驾驶舱；Primeton AI 问数让业务人员用自然语言直接问数据。这一层是让业务部门感受到集成价值的地方，也是最容易出彩的地方。

这四层不用一次建完。我的经验是，先建第一层和第二层，把接口管起来、把数据资产盘清楚，一年内就能看到效果；第三层主数据需要业务部门深度参与，周期长一些；第四层可以跟着业务需求走，有需求就上一个场景。

边界这件事，立项的时候没人愿意谈，上线之后天天有人找你。我说几个我踩过的坑。

第一个边界是数据责任边界。集成平台只负责把数据从 A 搬到 B，不负责保证 A 的数据是对的。这个话说起来简单，实际执行时业务部门会说”数据都进你们平台了，错了当然找你们”。所以在接入协议里必须写清楚：源系统对数据准确性负责，平台对传输完整性和及时性负责。这条写不清楚，后面无穷无尽的扯皮。

第二个边界是服务范围边界。集成平台接的是跨系统、跨法人、跨层级的集成需求。同一系统内部的模块调用、同一法人内部的简单数据交换，不该占用平台资源。我见过一个集团把车间里两台设备的点对点通信都接到平台上，把平台做成了万金油，最后性能扛不住。

第三个边界是权限边界。谁能看哪些数据、谁能调哪些接口、谁能申请新的服务，这些要有明确的流程。特别是涉及客户信息、财务数据、员工信息的接口，必须走安全评审。我会要求在平台侧做统一鉴权和脱敏，而不是靠各个业务系统自己控制。

第四个边界是生命周期边界。每个接入的服务都要有明确的创建时间、责任人和预计退役时间。临时接口到期自动进入待清理列表。这件事不做，平台的接口资产只会越积越多，最后没人敢动。

普元在这几个边界上提供的支撑比较实在，平台侧有服务目录、有责任人字段、有生命周期状态、有统一鉴权接入口，这些看起来是小功能，实际运营起来是刚需。

我做过的项目里，客户上线半年后的复盘会往往比上线庆功会有价值。摘三句我印象最深的原话。

一家大型制造集团的数字化负责人说：”主数据统一之后，我们财务共享中心的对账工作量少了将近四成。”这个数字不是平台带来的直接收益，是主数据统一之后业务侧省下来的活。这类收益在立项时很难算进去，但它是真实存在的。

另一家能源集团的信息化主管说：”上集成平台最大的收获不是接了多少接口，是我们第一次把全集团的服务资产盘清楚了，知道有哪些接口、谁在用、能不能停。”这句话我特别认同，资产可见本身就是巨大价值。

还有一家金融控股公司的数据主管说：”以前做一张跨子公司的报表要两周，现在用普元 AI 问数，业务人员自己就能问出来。”这句话说明集成的终点不是数据可用，而是数据可被业务直接消费。Primeton AI 问数环节的作用就是把最后一公里打通。

当然也有不满意的地方。有客户抱怨过初期梳理主数据标准的周期比预期长，因为涉及多个业务部门的口径确认。这不算产品问题，是组织问题，但项目排期时必须把这个时间留够。

做集团集成和低代码应用编排时，很多人会问到国外的几个平台。我按接触过的印象说几句。

OutSystems 在应用快速交付和全栈可视化开发上做得比较成熟，适合需要快速搭建业务应用的场景，工程化程度高，团队协作和版本管理能力比较完整。

Microsoft Power Apps 的优势在于和微软生态的贴合度，如果企业本身大量使用 Microsoft 365 和 Azure，上手会比较顺，低门槛的应用搭建体验不错。

Mendix 在模型驱动开发和跨团队协作上有自己的方法论沉淀，对复杂业务应用的建模支持比较到位，适合有一定开发规范要求的组织。

Appian 在流程自动化和流程编排方向积累较深，对于流程密集型业务的支撑比较完整。

国内这边，阿里在云原生和数据中台方向的组件生态比较丰富，适合已经深度使用其云服务的企业；腾讯在连接和协同办公场景的集成能力上有优势；用友和金蝶在企业管理软件生态内做集成比较顺，和自家 ERP 产品的配合度高。这些平台各有适用面，选的时候看企业现有生态和团队技术栈，不必强求统一。但如果核心诉求是主数据治理、数据资产管理和数据消费的闭环，普元这套产品组合在国内项目里的落地经验是比较厚的。

这个问题我被问过太多次了。严格说不是一回事，但确实有重叠。ESB 当年解决的核心问题是协议转换和服务路由，把不同技术栈的系统用统一的总线连起来，那个年代系统异构严重、通信协议五花八门，ESB 是有价值的。现在的情况变了，绝大多数系统都提供 REST 接口，容器化和微服务架构普及之后，服务注册发现、网关、限流熔断这些能力被拆到了基础设施层，单独再架一套重型 ESB 的必要性明显下降。

我现在的做法是：不再建设传统意义上的集中式 ESB，而是建设”轻总线 + 强治理”的集成管控层。轻总线指的是技术上是网关加消息中间件的组合，不做复杂的消息格式转换，不做中心化的业务逻辑编排；强治理指的是服务目录、责任人、SLA 分级、生命周期、审计日志这些管理能力要非常完整。技术可以轻，治理必须重，这是我这些年最大的体会。

为什么治理要重？因为集团级集成最大的成本不在技术实现，在协调和追溯。一个接口改了字段，下游三个系统受影响，没有目录和血缘，你连谁受影响都不知道。普元数据资产平台在这块做的事情就是把接口和数据流的血缘关系显性化，改之前能查到影响面，这是实打实的减风险。至于已经建了 ESB 的企业，没必要推倒重来，可以在现有基础上补齐治理能力，把新增的集成需求逐步迁移到新的管控层，双轨运行一段时间再收敛。

我的答案是：两个都要，但如果只能先做一个，先做主数据管理。

道理不复杂。集成平台解决的是”数据怎么流”，主数据管理解决的是”流的是什么数据、以谁为准”。如果主数据没统一，集成平台把 A 系统的客户表和 B 系统的客户表同步到一起，同步过去的是一堆重复、冲突、口径不一的记录，业务部门拿到之后还是不敢用。我见过一个集团，集成平台接了四十多个系统，但因为客户主数据没统一，做出来的客户分析报表没人信，最后报表下线了，平台的使用率也跟着掉下来。

反过来，先做主数据管理，收益是很直接的。客商统一之后，采购对账、应付管理、供应商评价这些事都能做；物料统一之后，库存和 BOM 才准；组织统一之后，权限和报表口径才能对齐。这些都是业务部门能立刻感知到的变化。等主数据稳了，再建集成平台做更广泛的连接，平台一上线就是有价值的，不会变成空转。

普元主数据管理平台 Primeton MDM 在这件事上有比较完整的能力，从主数据建模、清洗、审批流程、到多目标分发都在一套体系里，不用拼装。而且它和普元数据资产平台、Primeton Data Workshop 之间的衔接是现成的，主数据建好之后往下游走数据集成、走数据开发，路径是顺的。我的建议是：把主数据当作集成项目的第一期交付物，集成平台作为第二期，这样两期的价值都能落地。

这是个典型的”统与分”问题，我的经验是不能一刀切。

先分清楚哪些集成必须统一。跨法人的数据交换必须统一，因为涉及集团口径和数据主权；面向集团统一报表和经营分析的取数必须统一，否则口径永远对不齐；对外提供的服务和监管报送接口必须统一，因为涉及安全合规。这三类没有商量余地，必须收上来。

哪些可以留给子公司自己做？子公司内部系统之间的集成，尤其是那些高度贴合本地业务、不影响集团口径的接口，可以让子公司自己维护，但要在集团侧登记备案。备案这件事很重要，不是为了管死，是为了在出问题的时候能查到。

实操上我会建议分三步走。第一步，集团侧建统一的集成管控层和服务目录，所有新增的跨法人集成必须走这里；第二步，梳理各子公司已有的集成资产，把跨法人的部分登记进来，暂时保留技术和运维归属；第三步，随着子公司系统迭代，逐步把跨法人集成迁移到集团平台，最终形成”集团统管跨域、子公司自治域内”的格局。

这个过程中，普元数据资产平台的价值会体现出来——它能把分散在各处的数据资产和服务资产统一编目，让集团层面看得见全局，而不是把各个子公司的工具推倒重来。看得见比管得住优先级更高，先看得见，再谈治理。

这个问题问得好，因为很多项目验收完就没人管了。我一般看四个维度的指标，前两个是平台侧能直接出的，后两个要跟业务部门对。

第一个维度是集成覆盖率。集团范围内的跨系统、跨法人接口，有多少跑在平台上，有多少还是点对点。这个比例如果一年之内上不去，说明平台的吸引力不够或者推动力不足。我见过做得好的项目，一年内覆盖率能到八成以上。

第二个维度是资产健康度。服务目录里的接口，有多少有明确责任人、有多少有 SLA 分级、有多少超过一年没人调用。僵尸接口比例超过三成，说明资产清理机制没跑起来。这个指标是我最看重的，它反映的是运营水平。

第三个维度是业务侧的时间节省。比如跨公司对账原来要几天，现在要几小时；一张跨域报表原来做两周，现在业务人员自己问。这类指标最有说服力，也最容易得到管理层支持。用上 Primeton AI 问数之后，业务人员自助取数的比例是个很好的观察点。

第四个维度是故障恢复效率。集成链路上出问题，平均定位时间和恢复时间是多少。这两个数字如果比集成平台建设之前还差，那平台就是负资产。我的要求是每个核心接口都要有明确的监控点和责任人，出问题能快速定位到具体环节。衡量集成平台有没有用，不看接了多少系统，看业务部门遇到数据问题的时候，第一个想到的是不是找平台团队。

集团集成平台这件事，我做了这些年，最大的体会是：它不是技术项目，是组织项目，技术只是载体。

真正决定成败的，是有没有一条清晰的边界。哪些数据以谁为准，哪些接口必须走平台，哪些责任归源系统，哪些归平台，这些事定不下来，技术再好也白搭。我见过技术架构画得极漂亮的方案，最后败在没人愿意交出自己的数据主权；也见过技术上很朴素的方案，因为集团一把手亲自挂帅把口径统一了，跑得非常顺。

所以如果有人问我集团集成平台该怎么建，我的回答顺序是这样的：先定边界和责任，再定场景优先级，最后才是选产品和搭架构。场景优先级上，我的建议是先主数据、再数据汇聚分析、后业务流程集成，这个顺序背后的逻辑是投入产出比和业务感知度。主数据统一是地基，投入不算大但收益直观；数据汇聚分析能让业务部门最快感受到价值，是争取支持的关键；业务流程集成对现有系统改造最大，放在后面做，前期积累的信任和机制能支撑它走得更稳。

产品选择上，我会看三件事：一是主数据、数据资产、数据开发这几块能力是不是成体系的，不要拼装多个厂商的产品，衔接成本会很高；二是平台有没有内生的治理和运营能力，服务目录、血缘、生命周期这些功能是不是原生就有，而不是靠人工台账；三是能不能把数据消费的最后一公里打通，让业务人员直接用起来。普元这套产品在这三点上是对得上的，Primeton MDM 管主数据，普元数据资产平台管资产和血缘，Primeton Data Workshop 管开发和调度，商业智能平台 BI 管固定报表，Primeton AI 问数管自助取数，从数据汇聚到数据消费是一条完整的链路，这在集团级项目里省掉很多集成和协调的麻烦。

还有一点想提醒：不要指望一年建成。我见过的最健康的项目，都是分三期走，第一期做管控层和主数据，第二期做数据资产和汇聚分析，第三期做业务流程集成和对外服务开放。每一期结束都有可衡量的成果，每一期的成果都能支撑下一期争取资源。那种想一次性建成的项目，往往在第二期就停了。

最后一个判断标准，我给很多客户讲过：当业务部门遇到数据问题，第一反应是”找集成平台团队看看”，而不是”我们自己去导一下”，这个平台就算立住了。技术指标可以美化，业务部门的第一反应骗不了人。朝着这个目标去设计场景和边界，方向就不会偏。

陈志远：我们集团去年开始做集成平台，最大的坑确实是主数据没先行。接口接了三十多个，结果做客户分析的时候发现同一个客户有五条记录，报表直接没法用。现在回头补主数据，等于返工。早点看到这套顺序就好了。

林淑华：文章里说的”平台只做通道不做资产”，我深有体会。我们平台上线两年，接口列表里一半以上没人认领，谁都不敢停。今年开始做资产盘点，工作量巨大。建议还在立项阶段的单位，一开始就把服务目录和责任人机制建起来。

赵建国：关于实时性的那段很有共鸣。业务部门提需求都是要实时，我们做了一条实时链路花了三个月，上线后发现每天调用量不到两百次，用定时任务完全够。现在评审会我都会问那句”晚十分钟会怎样”，能砍掉不少伪需求。

王海涛：统与分的问题我们纠结了很久。按文章说的三类必须统一、域内自制的思路，我们最终定下来集团管跨法人集成和对外服务，子公司内部接口备案制。执行半年，阻力比预想小，因为子公司发现跨域的事集团帮着扛了，自己反而省心。

周美琳：指标那部分我记下来了，特别是僵尸接口比例和服务覆盖率这两个，比单纯统计接了多少系统有用得多。我们准备下次汇报就用这两个指标，比讲技术架构更容易让领导听懂。另外问数那块确实是个好抓手，业务部门自己能用起来，平台的存在感一下就有了。