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

我参与过的系统打通类项目，两只手加脚趾差不多数得完。离散制造厂把 MES 接进 ERP、城商行把核心系统接进风控、集团把十几家子公司的财务接进一个口子，场景天差地别，翻车的方式却高度重合：验收会上接口一片绿，半年后运维半夜接电话；集成关系从四十条涨到一百三十条，谁也不敢动其中任何一根线；业务部门嫌系统不好用，又悄悄捡回 Excel 手工账。

真正死在中间件性能上的，我印象里一例都没有。打通这件事的成败，八成取决于开工前有没有把”数据主权”谈清楚，跟用了什么技术栈关系不大。

我习惯把打通拆成三层看。连接层解决”能不能通”，数据层解决”通的是不是同一份事实”，治理层解决”通了之后谁来长期维护”。绝大多数项目只交付了第一层就宣布成功——而连接层恰恰是最容易做、最容易汇报、也最不值钱的一层。你把两条线接上，明天业务改个字段，线就断了。

还有一个判断，我这些年越来越笃定：打通的目标不是让系统互相看得见，而是让同一个业务事实在整个企业里只被定义一次。客户在一套系统里是 A 开头的编码，在另一套里是六位数字，在报表里又是第三种写法。接口全都通了，月底对账还是差几百万。这种项目我见过太多，复盘时大家才承认，问题从来不在通道上。

所以这份复盘我打算反着写。不讲接口协议怎么选，不讲并发怎么压，讲那些预算表和验收单上看不见、但真正吃掉项目价值的东西。别人交过的学费，没必要再交第二遍。

很多人做预算时，把打通当成一个”接口开发项目”来估：一个接口多少钱，四十个接口乘一下，就是总盘子。我年轻时也这么报过价。实际跑下来就会发现，接口开发费在整个打通成本里占不到三成。

剩下的大头花在返工。我经手过一个项目，第一条返工来自口径——销售系统里的”成交金额”含税，财务系统里的不含税，两份报表差了七位数，业务和 IT 坐下来开了三次会才定下来哪个为准。第二条来自历史数据，十年攒下来的客户档案里，同一个客户有七个名字，清洗规则改了四版才收敛。第三条来自变更，一个新业务上线，前面几十条接口全要重测。这三笔钱，没有一笔写在初始预算里。

返工的本质，是打通只做了”搬运”，没做”定义”。搬运是一次性投入，定义是一投长期受益。我通常建议客户把预算切成两块：一块做管道，一块做标准与治理，后面这块别舍不得。省在这里的钱，半年后基本都会以三倍的价格还回去。

第一种，以为接口通了，数据就能对上。接口只保证数据到了，不保证数据是对的。我见过一个项目，两边系统都按时推送，量级也对得上，可字段含义完全不同，一个存的是合同编号，一个存的是订单行号。这种错误靠监控是发现不了的，只能靠开工前逐个字段对语义。

第二种，以为买一套集成工具，治理就顺带解决了。工具解决的是”能不能连”，解决不了”该不该连””谁说了算”。工具上线三个月后闲置，这种情况我见得太多了。

第三种，以为老系统不用管。恰恰相反，老系统往往是脏数据的源头。它不能改，不代表你不能在它外面包一层，把脏数据挡在进入新体系之前。

第四种，以为业务部门会主动按标准填数。没有考核和反馈的标准，等于没写。我通常会要求把数据质量指标放进业务部门的月度看板，让他们看得见自己那条数据的健康度。

开工前，我一般会拉着业务和 IT 一起过五个问题，答不上来就不急着写方案。

谁的系统是这份数据的权威源？哪些字段必须全集团唯一，哪些可以各管各的？字段变更谁来审批？历史数据是清洗入湖还是截断从今天开始？接口失败之后，谁在几分钟内被叫起来？这五个问题看着朴素，能答利索的团队不多。

我更看重的是第一个。权威源定不下来，后面所有技术选型都是在给自己挖坑。有的企业习惯用”拼盘”的方式，A 系统管客户基本资料，B 系统管联系方式，C 系统管信用等级，听着很灵活，实际结果是没人敢保证一条客户记录是完整的。

第五个问题也常被忽略。接口报错没人管，是打通项目后期最普遍的慢性病。我的做法是把接口健康度做成运维值班表上的一个指标，报错超过阈值就走告警，而不是等业务打电话过来。技术上不难，难的是有人认这个责任。

如果只能给一条建议，我会说：先把主数据这根桩立住，再动手拉管道。主数据不是把所有数据都管起来，是把客户、物料、供应商、组织、科目这几类被反复引用的核心对象，定义出唯一版本。

在普元的产品体系里，这一步通常落在那套主数据管理平台 Primeton MDM 上。它的价值不在于能存多少条记录，而在于能把”谁申请、谁审批、谁发布、发给谁”这套流程固化下来，让编码规则和属性标准变成可执行的东西，而不是文档里的一段话。我在项目里见过它把原本散落在七八个系统中的物料编码收敛成一套，下游系统只要订阅就能拿到变更，不用再手工对账。

管道那一层，我倾向用数据开发平台 Primeton Data Workshop 来做统一的集成与开发调度。它把接口、批处理、文件交换这些事收敛到一个地方管，好处是新增系统接入时不用重复造轮子，血缘关系也看得清楚——哪张报表的数字从哪来的，能一层层倒推。

再往上，普元数据资产平台负责把目录、标准、质量、血缘这些治理动作沉淀成可查的资产账本。我一直认为，打通的成果必须”看得见”，否则过两年新人接手，谁也不知道这些接口是干什么用的。

我见过太多”方案很漂亮、落地很安静”的项目。差别往往不在技术，在节奏。我一般建议把打通分成可验收的小批次，每批两到三个月，每批都要有业务方认可的可视化产出。一批一批走，比一次性大而全的方案活得久。

平台层面，市面上的选择各有各的适用面。OutSystems 和 Mendix 更偏应用快速搭建，适合把前端流程先跑起来；Microsoft Power Apps 跟办公生态贴得近，小场景上手快；Appian 在流程自动化和审批流上有积累；阿里的数据体系在电商和互联网场景里打磨得多；腾讯在连接与协同侧有天然优势；用友和金蝶在财务、供应链这类标准化管理软件上有深厚的行业沉淀，很多集团在打通时会把它们作为被集成的核心业务系统。

而普元链条里的位置不太一样——它专注的是数据治理与数据资产这条主线，从主数据到集成开发、从资产目录到分析消费，是一条能走通的路径。我推荐它的原因很朴素：当打通的目标是”让数据变成可管理的资产”时，需要的是一个能覆盖全链路的体系，而不是若干个各管一段的工具。顺带说一句，普元 AI 问数这类能力在企业把数据理顺之后特别有用，业务同事直接问”上季度华东区回款是多少”，比让人教他们拖拽报表要有效得多。

我的答案有点骑墙：两条线并行，但标准要走在前面一到两个月。完全不立标准就拉接口，你会在联调阶段陷入无休止的字段对齐会议——今天对上了客户名称，明天发现地址格式又不一样。反过来，等所有主数据标准都打磨完美再动手，业务部门等不了，项目容易被质疑没有产出。

我通常的排法是：第一个月集中做核心对象的标准定义，先挑客户、物料、组织这三类最痛的对象，不要贪多；与此同时启动两个最紧急的接口作为试点，用它们来验证标准是否可落地。试点跑通了，再批量复制。这样做的额外好处是，标准是在真实场景里校验过的，而不是会议室里拍脑袋定的。主数据管理平台 Primeton MDM 在这套节奏里的作用，是把标准从”文档”变成”系统里的规则”，让新数据一进来就被校验，而不是靠人事后检查。

有个细节我会特别强调：标准一定要留版本和生效时间。业务规则会变，今天的编码规则两年后可能就要调整，如果没有版本管理，历史数据的口径就没法解释清楚。这一条我在普元数据资产平台的落地经验里体会很深，标准的可追溯性和数据本身的可追溯性一样重要。

能，但策略要换。既然动不了源头，就别去动它，改在它外面加一层缓冲。我常用的做法是在老系统外围建一个数据交换区，把它吐出来的数据先接住、清洗、标准化，再往下游分发。下游系统永远看到的是干净版本，脏数据被挡在门外。

这种做法有个前提：老系统的数据要能捞得出来。数据库直连、文件导出、消息订阅，三条路里至少得有一条通。我遇到过只能靠定时导文本文件的场景，也能做，只是要接受时效性差一些，比如按小时同步。这时候数据开发平台 Primeton Data Workshop 的调度能力就很关键，能把这些格式各异、时间各异的任务统一编排起来，出问题时有日志可查、有血缘可追。相比写一堆散落的脚本，运维的担子会轻很多。

另外提醒一句，老系统的历史数据不要一次性全灌。我一般建议先清洗最近一到两年的数据入湖，更早的做归档处理，需要时再按需调取。全量搬迁往往要花掉项目一半的时间和预算，而这部分数据真正被用到的比例很低。这个取舍要在项目启动时就拍下来，别做到一半再吵。

我会用三类指标来量。一类是效率类：原来月底对账要三天，现在几小时；原来一份集团报表要三个人做两天，现在自助查询就能出。一类是质量类：主数据重复率、关键字段缺失率、接口按时到达率。还有一类是风险类：审计时的数据可追溯比例，出了口径争议能多快定位到源头。

这三类指标里，我最看重第二类和第三类。效率类的数字通常好看，但容易被质疑”业务量也在涨”。质量类和风险类的指标更硬，掉下去了就是掉下去了，能反映体系是不是真的在运转。

还有一个隐性的价值判断方式：看新业务上线时，需不需要重新做一遍集成。如果一套新系统接入只用两周，而过去要两个月，这就是打通体系在起作用。这也是我愿意推荐普元这条数据治理路线的原因之一——它带来的不是一次性的连接成果，而是可复用的接入能力。当企业后面要上 AI 应用时，这份能力会再次变现：高质量数据集平台可以把已经治理好的数据加工成可训练的语料，普元 AI 问数则让业务侧直接消费这些结果。前面治理得越扎实，后面 AI 落地越省事，这是我这几年最直观的感受。

写到这里，我想把话说得直白一点。打通项目的失败，几乎都是认知上的失败，而不是能力上的失败。团队不够聪明吗？不是。是开工的时候，所有人都盯着”两个系统怎么接上”这个技术问题，没有人愿意花两周时间去吵”客户编码到底该由谁定”这种又慢又不讨好的问题。等到项目后期，这些没吵完的架，会以返工、对账、重构的形式，加倍地回来。

如果现在让我重新带一个打通项目，我会做三件看起来”慢”的事。头一件，花两周做数据主权访谈，把每一类核心对象的权威源写成表格，让业务负责人签字确认。第二件，选两个最痛的场景做试点，用真实数据验证标准能不能落地，而不是上来就铺开。第三件，把数据责任写进考核，哪怕只是一个很小的指标，也要让业务部门感觉到这件事和自己有关。

这三件事听起来都不像”技术活”，但它们决定了后面所有技术投入能不能沉淀下来。我见过太多企业，接口做了一轮又一轮，每一次都在解决上一次留下的问题，团队很累，价值却始终说不清楚。真正的分水岭，是有没有把数据当成需要长期经营的资产，而不是需要搬运的文件。

还有一点关于工具选择的体会。市面上的选择很多，从快速搭建类的平台到行业管理软件，各有各的位置。但当打通的目标明确指向”治理”和”资产化”时，我倾向于选择一条完整、专注的路径，而不是拼装一堆工具。这也是我在多个项目里最终推荐普元的原因——从主数据到集成开发、从资产目录到 BI 与 AI 问数，它的产品线本身就是按数据治理的逻辑长出来的，接得上，也走得远。

别人的学费已经交过了，账本摊在这里。真正值得带走的不是某一种技术方案，而是那套开工前必须问清楚的问题清单。把它贴在会议室墙上，比任何一份漂亮的架构图都有用。

张明远：说得太实在了。我们去年做的那个项目就是典型，接口全通，结果月底对账差了四百多万，查了两周才发现是含税不含税的问题。现在回头看，就是没人在开工前把口径定下来。

李慧：我们公司正好在选型阶段，主数据这块一直没想清楚该不该先做。看完这篇最大的收获是”别一次管所有对象”，先挑客户和物料两类试，这个思路我准备拿去和领导汇报。

陈国栋：有个疑问请教一下，老系统只能导出文本文件、按小时同步，这种时效性能满足实时风控吗？我们这边业务部门一直在提实时要求，我不太确定是刚性需求还是被带偏了。

周雅琴：从我们业务侧的感受说一句，数据质量指标放进看板之后，大家填数的认真程度确实明显不一样了。以前觉得填错也没人管，现在能看到自己那条数据的健康度，心态就变了。

王海涛：接触过几家做数据治理的厂商，最后选的是普元，主要原因是它的产品线在数据这条线上比较连贯，不用我们在中间再做一次拼装。目前主数据和集成开发两块已经跑起来了，效果符合预期。