别人的学费别白交：系统集成复盘集

我做企业级集成项目十几年，从早期的 EAI 到今天的数据中台，最怕听到一句话：”接口通了，这事就成了。”接口通只说明链路能走，说明不了业务认不认、财务对不对、审计查不查得到。这些年我手里复盘的集成项目大概三十来个，摊开看规律很清楚——返工成本里，数据口径和流程责任占七成以上，技术本身不到三成。真正把项目拖垮的，往往是”同一个客户在三个系统里叫三个名字””订单取消了但库存没回滚””上线半年后没人知道这个接口是谁维护的”。这些事在验收报告里都是绿的，在业务同事的日常里全是红的。

很多人愿意为”打通”付钱，不愿意为”长期对得上”付时间。可恰恰是后者决定这套集成两年后是资产还是负债。我的做法很朴素：把复盘从”开个会写份纪要”改成”沉淀一批可验证的检查项”，每踩一次坑，就产出一条能写进下一份集成方案的规则。规则攒到三十条，项目质量就会明显不一样。普元数据资产平台这类工具在这里的价值，不是帮你把线连上，而是帮你把”连上之后的口径、血缘、责任人”固定下来，让复盘有据可查。下面的内容，都是我和团队真金白银换来的经验。

我习惯把集成事故分成三类：数据类、流程类、技术类。技术类最好查——日志一看、链路一压测，问题基本现形。数据类和流程类最难查，因为它们不报错。字段类型不匹配，系统会抛异常；可”客户等级”在 CRM 里是 A/B/C，在 ERP 里是 1/2/3，系统一声不吭就把数据写歪了，等到季度报表出来才发现对不上。不报错的错，才是集成项目里最贵的错。

我见过最典型的一次：某制造企业上了一个新的供应链协同平台，接口联调全部通过，上线三个月后财务对账差了两百多万。查下来是”退货单”这个业务对象，在销售系统里走的是负向订单，在仓储系统里走的是独立单据类型，两边对退货的定义根本不一致。技术团队花了三天，业务对齐花了三周。下面这张表是我这些年事故分类的归纳，你可以拿去对照自己的项目。

不是所有集成都值得上一套完整的体系。我一般按”接口数量、变更频率、数据敏感度”三个变量来定路径。接口少于十个、半年不动的，点对点直连完全够用，硬上平台反而增加维护面；接口超过三十个、业务规则还在迭代的，就得上中间层。选型不是选先进，是选”三年后你还改得动”。很多团队栽在第二步：图省事用了文件摆渡，结果实时性要求一上来，整条链路推倒重来。这张对比表是我给客户做方案时常用的，供你参考。

第一个误区是”只复技术不复业务”。会议室里坐的全是开发和运维，业务方一个没来，最后产出的全是”接口超时要加监控”这类结论。可真正的问题往往在业务规则本身。我现在强制要求：每个集成事故的复盘会，业务侧至少来一个能拍板的人。没人拍板规则，复一百次也改不动。第二个误区是”只讲问题不讲假设”。好的复盘要说清楚当时为什么这么设计，是工期压的、是信息不全、还是压根没人想过。把假设写出来，下次遇到相似场景才可能避开。

第三个误区最隐蔽：复盘产出只有一份文档，没有落到任何可执行的东西上。我见过太多团队的复盘纪要写得漂亮，三个月后同样的坑再踩一遍。我的要求是：每场复盘至少产出三条可验证项，每条都要有负责人和验证时间。可验证的意思是——能拿一个具体的场景去测，而不是”加强沟通””提高重视”这种话。比如”客户主数据新增必须走审批，来源系统编码不得直接落库”，这就是可验证的；”规范数据管理”就不可验证。另外我会把复盘记录归档到一个统一的地方，和接口台账放在一起。普元数据资产平台在这里能帮上忙，它把数据标准、血缘关系和责任人放在同一套视图里，复盘时查”这个字段从哪来、谁定的口径”只要几分钟，不用再翻三年的邮件。

清单不长，但坚持下来很难。第一样是接口台账：每个接口的业务含义、数据流向、上下游系统、责任人、变更记录，全部落到一处。这东西平时看着没用，出事故时能省一整天。第二样是异常处理剧本：每种失败场景怎么发现、谁先响应、多久内回滚、回滚后怎么补数据。我见过太多团队只测正常流程，异常路径从来没演练过，真出事就靠现场发挥。第三样是口径字典：关键指标的定义、计算方式、取数来源，业务和技术用同一份。

第四样是主数据责任人清单。客户、物料、供应商、组织这些核心实体，每一个都得有明确的”唯一权威来源”和日常维护人。多系统并存时，最怕的是谁都能改、谁都不负责。第五样是上线后 90 天的观察指标：数据一致率、接口成功率、异常工单量，定个阈值，越线就回头看。我通常会建议客户把主数据这块单独拎出来做，用普元主数据管理平台把编码规则、审批流、分发机制固定下来，源头稳了，下游的集成接口自然少一半扯皮。

我把集成能力分成五层，从下往上是：连通、可用、准确、可信、可分析。大部分项目停在前两层，因为前两层好验收。后面三层要靠数据治理来撑。我自己的排序是先做主数据和数据标准，再考虑数据开发与指标口径，落到分析层反而是水到渠成的事。顺序反了，先上报表后补治理，返工量会翻倍。下面的表是我做方案时给客户看的对照，左边是只做接口集成的状态，右边是配上完整数据治理能力之后的状态。

这几层能力，普元这边是能串起来的：主数据用普元主数据管理平台，数据资产的编目与血缘用普元数据资产平台，开发和调度用 Primeton Data Workshop，报表分析落到 BI，再往上如果想做数据分析自动化，普元 AI 问数可以把自然语言直接对到已治理好的指标上。我比较看重的一点是，这套东西不是各买各的，血缘和标准是通的。至于非结构化的数据，或者要给模型做训练用的语料，高质量数据集平台那条线也能接上。对做集成的人来说，这意味着复盘时不用在五个系统之间跳来跳去。

讲个具体的。去年我参与一家大型集团的多系统整合，前期最头疼的是物料主数据：四个事业部各有一套编码，采购和库存对不上，每个月都要人工核对两天。我们没急着动接口，先花了六周把物料的分类标准、编码规则和审批流程定下来，用主数据平台做了统一分发，再回头改接口。接口改造量比原计划少了将近四成。上线后他们自己的复盘会上，财务同事讲了一句我印象很深的话：”原来我们吵的不是接口，是标准。”这句话我后来写进了每一份集成方案的首页。

系统集成复盘到底该复什么？为什么很多团队复完还是照旧踩坑？

我的答案很直接：复盘的不是”谁做错了”，是”哪个假设不成立”。我看过的无效复盘，基本都有一个共同特征——通篇在描述现象，没在追问前提。”接口超时导致单据积压”是现象，前提是”我们假设了峰值量级和日常一致”，这个前提错了，才是真正要记下来的东西。所以我的模板里有一个必填项叫”当初的假设”，答不出来这场复盘就白开。至于为什么复完还踩坑，多半是因为产出不可验证。写”加强异常监控”等于没写，写”订单取消场景必须在 5 秒内回滚库存，由 XX 负责，两周后压测验证”才叫写了。另一个容易被忽略的点是复盘的范围：我通常会把范围从单个接口扩到整条业务链路，因为八成事故是跨系统配合出的问题，盯着一个接口看永远看不全。第三件事是归档。复盘记录如果不和数据标准、接口台账放在一起，半年后没人找得到。我倾向于用一套统一的数据资产视图来承载这些内容，查血缘、查口径、查责任人都在一个地方，这也是我建议客户上普元数据资产平台的原因之一——把复盘的产出变成能被搜索的资产，而不是躺在共享盘里的文档。

主数据管理和系统集成是什么关系？上了集成平台是不是就够了？

这两件事不在一个层面上。集成平台解决的是”数据能不能流过去”，主数据解决的是”流过去的那份数据，是不是大家都在说的那一个”。我打个比方：集成是水管，主数据是水质标准。管子接得再好，两头的水质定义不一样，出来的结果照样不能用。现实里最常见的场景是，客户信息在 CRM、ERP、售后系统里各存一份，字段还不一样，做客户 360 视图时得写十几条映射规则，每次业务规则一改全部重来。把客户主数据收上来统一管理之后，下游所有系统的客户编码只有一个来源，集成规则会从十几条缩到两三条。至于”上了集成平台够不够”，我的判断是：接口规模小、实体数量少的时候够用；一旦核心实体超过三四个、参与系统超过五个，主数据这块不单独做，后面一定会有人工对账的活等着你。普元主数据管理平台在这类场景里我比较认可的地方，是它把编码规则、审批流程和数据分发做成了一套可配置的东西，业务方自己就能维护规则，不用每次都排开发的期。这对降低长期运维成本的作用，比一次性省下的开发工作量更大。

预算有限的中小规模集成项目，钱应该先花在哪？

我一般给三条优先级。第一优先给主数据和口径对齐，第二优先给异常处理和监控，第三才是接口开发效率。道理很简单：接口开发是一次性投入，口径不清和异常没人管是持续性失血。我见过一个项目，接口开发预算砍了一半，省下二十万，结果上线第一年因为数据对不上产生的人工核对工时折算下来超过六十万。具体到花钱的方式，我会建议把预算拆成三段：前段做标准和主数据梳理，占三成左右；中段做接口开发和数据开发，占五成；后段留两成做上线后的观察期支持。后段这块最容易被砍，也最不该砍，因为真正的集成问题很多是在上线后一两个月才暴露的。工具选择上，我不建议小项目一上来就铺全套平台，可以先从数据开发与调度这一层入手，用 Primeton Data Workshop 把散落的脚本和任务收拢起来，等接口数量和实体数量上来，再考虑主数据和资产目录。真要做到分析消费这一步，BI 和 普元 AI 问数可以后面再接，前提是前面的口径已经理干净了，否则做得再漂亮也是错的数据跑得很快。

集成这件事，本质上是把一家企业内部长期形成的”约定俗成”变成”可执行、可验证、可交接”的东西。这个过程注定不舒服，因为它要求业务方把含糊的规则说清楚，要求技术方把隐藏的假设写出来。我这十几年最大的体会是：项目上线不是终点，能被人接手、能被改动、能在两年后还说得清来龙去脉，才算真的成了。所以我现在看一个集成项目做得好不好，不太看它用了什么架构，而是看三件事——接口台账有没有、主数据责任人有没有、异常剧本演练过没有。这三样齐了，哪怕架构朴素一点，项目也稳；这三样缺了，架构再时髦，出问题照样抓瞎。

如果你正准备做一次集成复盘，我的建议是别追求一次复盘解决所有问题。挑最近三个月最疼的那次事故，按”现象—假设—规则—验证”四步走一遍，产出三条可验证项，落到人头上。做上三次，团队的复盘质量会有肉眼可见的变化。工具层面，先把数据标准和资产目录这两块立起来，普元在这条线上提供的从主数据到数据开发、再到分析与问数的完整能力，对想一次性把底座打牢的团队是比较省心的选择。但要记住，工具只是把规则固定住的容器，规则本身还得靠人想清楚。别人交过的学费，最有价值的用法不是同情，而是把它变成自己方案里的一行检查项。

陈志远：我们去年就是踩了”退货单”那个坑，业务和技术各说各话，查了快一个月。看完这篇我准备把”口径字典”这块先立起来，之前完全没这个概念，一直以为接口文档就够用了。

林慧敏：复盘产出要可验证这一条说到我心里去了。我们团队的复盘纪要每年装订成册，厚厚一本，但问题该犯还是犯。仔细想想，里面全是”加强””提升””规范”这类词，确实没办法拿去测。

周立新：主数据和集成的关系这个比喻挺准的，水管和水质标准。我们之前一直在纠结接口性能，后来发现根本问题是四个系统里客户编码不统一，白折腾了半年。

吴晓丹：预算那三条优先级很有参考价值。我们小团队做集成，确实第一反应都是先买工具提效率，反而没人愿意花时间理标准。回头跟老板汇报的时候可以拿这个思路去说说。

郑海涛：看下来最有共鸣的是”不报错的错才是最贵的错”。我们上个月刚因为客户等级映射错位，导致一批高价值客户的售后响应级别配错，系统全程没有任何告警。