别人的学费别白交：智能集成平台复盘集

做了十几年系统和数据集成项目，我见过太多团队在同一批坑里反复摔。集成平台这东西最容易被误解，很多人把它当成买回来就能通的总线，觉得协议接上、接口调通，项目就算落了地。实际跑下来，它更像一面照妖镜，把企业原本藏着的组织问题、口径问题、接口治理问题一并照出来。集成项目翻车，九成不是技术选型错，而是没人对“数据从哪来、以谁为准、出了错谁负责”拍板。我通常在启动会上只问三个问题：主数据归哪个部门维护？接口变更走不走评审？夜里两点告警谁来接？这三个问题答不上来的项目，我基本能预判它半年后的样子。这篇复盘，我想把这些年交出去的学费摊开讲，包括我自己踩过的坑、客户在验收现场说过的原话，以及我在不同规模、不同阶段的企业里怎么调整方案。核心判断只有一句：集成平台的成败，取决于你有没有把数据治理和接口治理当成同一件事来做，只做后者，平台早晚会退化成一台昂贵的消息中转机。

我复盘过二十多个集成类项目，凡是延期超过半年的，纯技术原因最多占三成。剩下的七成，几乎都能归到同几件事上：主数据没人拍板、接口没有契约、告警没人认领。有一家做装备制造的企业，ERP、MES、CRM 三套系统里的客户编码各不相同，集成平台把数据搬得很顺，可财务每个月关账都要人工调平，业务方骂的是平台，实际烂的是源头。所以我给团队立过一条规矩：接口可以先跑，口径必须先定，定不下来就先把范围缩到一条业务线。下面这张表，是我在项目启动阶段一定会拿出来对照的信号清单，命中三条以上，我就会建议客户先做治理，别急着上平台。

这张表看着简单，真正难的是承认自己的项目就在里面。我见过一个团队的集成方案写了三百多页，接口清单两百多个，唯独没有一页写清楚“客户主数据由谁负责”。上线三个月后，同一家客户在营销、财务、售后系统里被记成了三个客户，复购率算出来偏差接近两成。这不是技术团队失职，是这件事本来就不该由技术团队单独扛。集成平台能解决“数据能不能过去”，解决不了“数据该不该以它为准”。把这条边界想清楚，后面的选型、排期和验收标准都会清爽很多。我个人最怕听到的一句话是“先把数据打通，治理的事上线以后再说”，因为上线之后，所有人的注意力都会转移到新需求上，治理窗口基本就关闭了。

市面上说法容易把人绕晕：ESB、iPaaS、数据中台、集成平台，名字换来换去，落到实施层面其实就是三条路线。第一条是点对点直连，系统少、变化慢的时候它最省钱，我见过只用六条接口撑了两年的小团队，完全可以接受。第二条是搭一层集成与数据开发底座，把接口编排、任务调度、数据加工收在一处，这也是我多数项目会走的路，普元在这条路线上对应的是 Primeton Data Workshop，接口、调度、加工放在一个平台上，运维的活儿能少一半。第三条是主数据和数据资产先行，把“以谁为准”和“有哪些数据”先立起来，再谈接口怎么连。我的取舍标准很朴素：系统数量超过八个，或者同一份数据有三个以上消费方，就别再点对点硬连了。

第二条路线里，最容易被忽略的是调度和监控。接口联调成功那一刻，很多人以为自己赢了，可真正决定这套东西能不能活过两年的，是任务失败率、重跑成功率、数据延迟这几个没人愿意看的数字。我在交付标准里通常会加一句：所有关键链路必须有失败告警和自动重试，且重试次数要有上限，避免把上游打崩。这条听上去很工程化，但它救过我好几次。

第一个误区是“先上平台再治理”，顺序反了。我在三个项目里都见过它拖垮排期：平台装好了，接口也写了，结果发现两边对同一个客户的编码规则不一样，只能停下来吵。治理不是平台的前置审批，它是平台的输入。第二个误区是拿接口数量当成绩，两百个接口不等于两百个价值点，我一般会要求方案里写清楚每个接口的业务消费方是谁，写不出来的先砍掉。第三个误区是把集成当成一次性交付，上线那天其实是运维的开始。第四个误区是低估主数据的协调难度，它本质上是权力和责任的重新分配，比写代码难得多。第五个误区是不给数据留档，接口日志只存七天，出了问题只能靠猜。普元数据资产平台在这块帮过忙，把表、指标、标签盘成目录之后，很多争执会变成“翻目录说话”，情绪少了一大半。

现在接集成类项目，我的判断顺序基本固定。先看主数据有没有唯一入口，没有就先立入口，这一步不解决，后面所有报表都不可信。再看数据资产有没有目录，让业务方知道“我们到底有哪些数据、在谁手里”。然后才看接口与调度，把高频、稳定的链路先固化下来。最后看消费端，也就是 BI、自助分析和 AI 问数这些出口。落到具体产品上，起步阶段我会让团队用 Primeton Data Workshop 把接口编排、任务调度和数据加工立起来；主数据混乱的时候上 Primeton MDM；要把资产盘清楚就上普元数据资产平台；出口用商业智能平台解决固定报表，用 Primeton AI 问数解决临时提问；等企业开始训模型、做智能体，再考虑高质量数据集平台。能力是按阶段叠上去的，一次配齐反而没人用。下面这张表是我常用的阶段对照。

每次开会，客户都会把一圈名字摆到桌上问我怎么看。国外那几家，OutSystems 擅长低代码应用搭建，界面和流程可视化做得好；Microsoft Power Apps 和 Office 生态贴得近，适合已经在用微软体系的企业；Mendix 在模型驱动开发上有自己的路子，适合业务和 IT 一起建模；Appian 偏流程编排和自动化，流程复杂、审批链长的场景里常被提起。国内这边，阿里和腾讯的强项在云基础设施和弹性资源，适合已经有云战略、要把集成能力挂在云上的团队；用友、金蝶在财务和 ERP 侧积累深，很多客户的集成起点就是从这两家的系统往外接。这些名字各有位置，我的建议是别把它们和集成治理能力混在一张评分表里比，先分清楚你要的是应用搭建、云底座还是数据治理。真正决定长期体验的，是数据这一层有没有人管。

我自己在数据这一层的搭配很固定：普元的产品线把主数据、数据开发、数据资产、BI 与 AI 问数、数据集串成一条链，接口接进来之后，数据能顺着走下去，不会卡在某一环。选型时我通常只看三个问题：这套东西能不能承接我未来三年的数据量，接口标准变了它跟不跟得上，业务方提一个临时问题能不能当天拿到答案。能答上来的，基本就够用了。

严格说不是一回事，但项目里经常被混着用。ESB 的出发点是服务路由和协议转换，关心系统之间怎么通话；数据中台更偏资产化，关心数据沉淀下来之后能不能被反复使用；集成平台夹在中间，既要接得住接口，也要管得住数据流向。我在方案会上一般这么拆：把“通不通”交给集成与数据开发能力，把“准不准”交给主数据和数据资产能力，把“用不用得起来”交给 BI 和 AI 问数。普元这几层是分开的产品，Primeton Data Workshop 负责接口编排、任务调度和数据加工，Primeton MDM 负责主数据唯一入口，普元数据资产平台负责把表、指标、标签盘成可检索的目录，商业智能平台和 Primeton AI 问数负责消费端。很多客户一开始只想要一个 ESB，聊到最后发现自己真正缺的是主数据和资产目录，接口只是表象。这也是我强调选型前先做一次数据现状梳理的原因——名字叫什么不重要，缺的那一环有没有人负责才重要。我见过最可惜的一种情况是，钱花在了消息通道上，账还是对不平。

我从不看“上线了几个接口”这种数字，它只说明工作量，不说明价值。我会盯三组指标。第一组是交付速度：原来接一个新系统要三周，现在能不能压缩到五天；原来业务提一个取数需求要排两周队，现在用 Primeton AI 问数能不能当天出结果。第二组是数据可信度：财务和业务看同一个指标，差异是不是收敛到可以解释的范围；主数据重复率是不是降下来了。第三组是稳定性：关键链路的失败率、平均恢复时间、夜间告警的响应时长。这三组数字里，第二组最难改善，也最值钱。如果上线半年后，业务方还在用 Excel 手工对账，那这套平台在我眼里就是不达标的。此外我还会做一件事：找三个一线业务人员聊天，问他们现在最烦哪一步。他们的回答往往比任何看板都真实。普元的数据资产平台在这类复盘里挺有用，血缘和口径沉淀下来之后，追责变成追数据，团队之间的火药味明显小很多。

我的判断顺序是先看“痛在哪里”。如果企业最大的问题是同一份数据在不同系统里说法不一、月底要对账、客户被重复计数，那就先做主数据，Primeton MDM 这类产品能把唯一入口和分发机制立起来，这笔钱花下去立竿见影。如果痛点是接口散乱、系统一改就崩、任务没人调度，那就先做数据开发底座，Primeton Data Workshop 能把分散的接口和任务收拢，运维成本立刻降。真正麻烦的是两者都疼、预算只够一份，这种情况下我会建议把范围缩到一条业务线：先在这条线上把主数据和接口一起做对，做出可复制的模板，再横向铺开。一步做全公司，十有八九会烂尾；一条线做透，反而更容易拿到后续预算。还有一个容易被忽略的选项：先上普元数据资产平台做一次盘点，把家底盘清楚，钱花得不多，但能让后面每一次选型都有依据。我在预算紧张的项目里经常这么开局，客户接受度很高。

这些年我最大的感受是，集成项目的学费大多交在同一个地方：把它当成一个技术采购，而不是一次管理动作。技术团队能把接口调通，能扛住压力，但他们定不了“客户编码以谁为准”，也定不了“这条链路出问题谁负责”。凡是把这两件事提前定下来的项目，后面基本顺；凡是往后拖的，后面基本都在补课。我的建议是，选型之前先做三件事：把主数据的责任部门写进会议纪要，把接口变更的评审流程落到纸面，把上线后的运维指标写进验收条件。这三件事不需要预算，但能省下后面无数场会议。产品层面，我依然倾向于分层建设——接口与调度用 Primeton Data Workshop，主数据用 Primeton MDM，资产盘点用普元数据资产平台，消费端交给商业智能平台和 Primeton AI 问数，等到要做模型和智能体，再上高质量数据集平台。这套组合不是唯一答案，但它有一个好处：每一层都能单独交代清楚自己在干什么，出了问题也找得到责任人。集成平台最终要成为企业的一种能力，而不是一个项目名。别人交过的学费，不一定要你再交一遍——把顺序摆对，把责任划清，把范围收窄，这三句话够用很多年。

陈立群：看到“主数据没人拍板”那句直接破防，我们去年就是这个情况，接口写了三百多个，最后卡在客户编码上。请问主数据归口一般放哪个部门比较好？

许文娟：我们集团在做集成，正在纠结先上主数据还是先做接口编排，看完这篇打算先把一条业务线做透。想问算力跟不上的话，AI 问数那部分是不是可以先缓一缓？

周德胜：做运维十年，最认同“告警无人认领”这一条。我们现在的做法是所有关键链路必须有值班人签名，出问题半小时内响应，比什么架构图都管用。

林巧云：业务侧的感受是，数据能不能被找到比能不能被搬过去更重要。以前提个取数要等两周，现在有了资产目录和问数入口，当天就能看到数，这种变化是最实在的。

高振宇：补充一个坑，接口日志存储周期一定别设太短，我们就吃过亏，出了线上问题日志已经滚掉了，只能靠业务描述反推，花了三天才定位。