破除系统打通迷思：回归业务本质

我做数据这一行快十五年了，经手过的”系统打通”项目，少说也有三十来个。能在一年后还愿意拿出来当案例讲的，不到三分之一。多数项目不是败在技术上，是败在目标一开始就定歪了。业务部门嘴里的”打通”，往往指的是”我在一个界面上能看到全部信息”；IT 部门理解的”打通”，是接口对得上、字段能互传；老板心里的”打通”，是想让报表别再打架。这三个诉求，背后要花的钱、要动的组织、要耗的时间，差着十倍不止。我把它们混在一张预算表里，项目就一定会失控。

我的判断很直接：系统打通的第一性问题不是连通性，而是口径唯一性。同一个客户，在 CRM 里叫”上海某某科技有限公司”，在 ERP 里叫”上海某某科技”，在财务系统里是一串税号，这三条记录能不能被认成同一家——这才是决定成败的东西。接口可以外包，口径只能自己定，别人替不了你。

所以每次有人问我”我们这几个系统能不能打通”，我通常会反问三句话：客户主数据谁说了算？物料编码规则是写在文档里还是记在某人脑子里？业务上有没有一个明确的人，对这条链路的结果负责？这三句答不上来，先别谈接口。先回归业务本质，把”谁说了算、以谁为准、错了谁担”这三件事定下来，再谈技术选型。普元在这条路上给我印象最深的一点，是它不急着卖一套平台，而是先把主数据、数据资产、数据开发这几块地基摆清楚，再谈上面盖什么。

下面我把自己这些年的判断逻辑、踩过的坑、以及不同阶段该怎么取舍，摊开来聊。文章里有表格，也有我实际项目里的数字，你可以直接拿去对照自己的情况。

我见过太多这样的场景：验收会上，技术负责人打开监控大屏，几十个接口全绿，成功率 99.9%，一屋子人鼓掌。三个月后业务部门开始抱怨——订单状态在 ERP 显示”已发货”，在 CRM 里还挂着”待处理”。为什么？因为接口是单向推送，CRM 那侧有个超时重试的队列堵住了，没人盯着看。

接口的”通”，指的是消息发得出去；业务的”通”，指的是状态对得上、能追溯、能纠错。这是两个层面的事。前者靠中间件和开发工时，后者靠数据治理和责任人机制。

我判断一个打通项目是真通还是假通，会看三个指标。一是同一笔业务在两端的状态一致率，二是异常单据有没有人认领、认领之后多久处理，三是从发现不一致到修正完成的平均时长。第一个指标想做好看并不难，后两个才见真章。我见过一个项目，一致率常年 99.6%，看起来很漂亮，但异常单据积压了两千多条，最老的一条躺了七个月。

再往下拆，一次”打通”实际上叠着三层价值，投入和风险完全不在一个量级。

这张表我一般会直接摆在客户会议桌上。如果一场会上，业务方只提第一层和第

三层的诉求，中间那层没人认领，这个项目大概率会烂尾。我踩过这个坑：五年前一个制造企业的项目，链路层做得很漂亮，决策层的报表也上了，中间口径层因为两个事业部谁也不肯让步，硬是拖了一年半，最终报表还得靠人工对账。

把”打通”这个词拆开，我一般分成三种模式。它们之间不是升级关系，是适用关系，用错了就是纯浪费钱。有人一上来就想做第三种，我通常会劝他先回去算一笔账。

我经常举一个例子。一家做工程设备的客户，最初的口号是”所有系统全部打通”。我陪他们开了两轮会，最后把范围收到”客户与合同两支主数据 + 一套统一经营看板”。工期从原计划的十四个月压到五个月，第一版上线后业务部门自己提了第二批需求，节奏反而顺了。范围收窄不等于妥协，是把钱花在能被验证的地方。

反过来也有教训。另一家客户坚持要上跨系统的业务集成，订单从 CRM 直接驱动 ERP 排产，中间还牵扯 WMS 拣货。流程设计得好，但一家工厂的网络抖动频繁，事务回滚没设计完备，出现了两次重复排产，车间多备了料。事后复盘，问题不在技术方案，在于把强一致性的要求放到了不该放的链路上。这类需求，我现在的做法是拆成”事件通知 + 人工确认”，牺牲一点自动化，换回可解释性。

第一个信号，是业务方能不能用自己的话说清”打通之后我每天少做什么”。说不清，就是在赶时髦。我要求客户方的业务负责人在立项书上写一句具体的、可观察的改变，比如”月底对账从三天缩到半天”。

第二个信号，是口径争议有没有裁决机制。两个事业部对”有效客户”定义不一致，这不是技术问题，得有一个人能拍板，而且拍完能落地。没有这个机制，主数据平台上得再漂亮也会被绕过。

第三个信号，是数据质量的家底摸没摸过。我会要求先做一轮小范围的数据盘点：随便抽两百条客户记录，看看有多少条重名、多少条缺关键字段、多少条归属不明。如果重名率超过一成，先做清洗，别急着上集成。

第四个信号，是原来那套系统能不能被改造。有的老系统连数据库表结构都不给，只能靠人工导出。这种情况下硬做实时集成，成本会失控，改用批量同步更实在。

第五个信号，也是我最看重的，是有没有人愿意在项目上线后继续管这件事。打通不是一次性交付，是长期运营。没有运营责任人的项目，我见过太多上线即巅峰，之后数据一天天烂下去。

有一次，客户方 IT 总监拍胸脯说主数据规则已经统一了。我留了个心眼，抽了三百条物料记录核对，发现同一个轴承在两个事业部编了两个码，一个是”外购件”，一个是”自制件”，因为采购路径不同。这种差异不是错误，是业务现实。强制性统一有时候会破坏业务灵活性，聪明的做法是”标准 + 例外”，主数据体系里允许受控的例外存在。

还有一次，项目验收半年后，业务方突然说报表数和财务对不上。查了两周，发现是财务在年末做了一笔手工调账，没有走系统流程，导致数据资产里的口径和账面对不上。从那之后，我在方案里一定会加一条：线下手工调整必须留痕并纳入数据资产范围，否则再好的平台也架不住一个 Excel。

第三个坑更隐蔽。有个客户的数据开发任务跑了好几年，没人知道哪些任务还有人用。等到要做迁移的时候，一查有四百多个任务，其中小一半是废弃的。后来我们用普元数据资产平台把任务和下游报表做了血缘关联，砍掉了近四成冗余任务，迁移工期直接压缩。打通之前先知道”我有什么”，这件事的价值被严重低估了。

聊到具体选型，我不太喜欢一上来就报产品清单，得先看你要解决的是哪一层的问题。普元的产品线我是这么理解的：它没有堆一堆”万能连接器”，而是把数据从定义、开发到消费这条路铺完整。主数据管理平台 Primeton MDM 管的是”以谁为准”，企业数据资产管理平台管的是”我有什么、放在哪、谁在用”，数据开发平台 Primeton Data Workshop 管的是”怎么把原始数据加工成能用的东西”，商业智能平台 BI 和 AI 数据分析平台（普元 AI 问数）管的是”怎么看、怎么问”，高质量数据集开发工厂这一块，这两年问的人明显多了，因为模型要喂数据，脏数据喂进去就是灾难。

普元主数据管理平台 Primeton MDM 我最看重的是它对”受控例外”的处理思路。前面说过，强行统一会伤业务，它支持在统一标准下保留经过审批的差异，同时把这些差异记下来，让人知道为什么不同。这一点在集团型企业里特别管用，几家公司合并过来的数据，硬压成一个模子反而出问题。

普元企业数据资产平台解决的是”看不见”的问题。很多客户对自己的数据家底是模糊的，表在哪儿、谁在用、血缘怎么走，全靠问人。上了资产平台之后，盘点、编目、血缘、权限能在一处看到。我一般建议客户在打通项目启动前就先把资产盘一遍，哪怕只盘核心的三五个域，后面能省下大量扯皮。

数据开发平台 Primeton Data Workshop 我常用来承接加工环节。任务、调度、依赖关系集中管起来，交给谁维护、什么时候改过，都有记录。BI 和普元 AI 问数则是把结果送到业务手里的那一环。特别是问数这种交互方式，业务人员不用等排期，直接用自然语言问，前提是底下的口径已经统一过，不然问出来的答案还是各说各话。

顺带说一句生态。有些客户的to C 前端用的是低代码搭起来的，比如 Mendix 或 Microsoft Power Apps，这类平台确实能让业务人员自己拼应用，但它们的强项在交互层，数据口径这件事不归它们管。低代码解决的是”谁来搭界面”，普元这类数据底座解决的是”数据听谁的”，两者不冲突，是上下层关系。OutSystems 和 Appian 也是类似定位，做流程和体验很在行。国内这边，阿里、腾讯在云基础设施上有积累，用友、金蝶在企业管理系统上沉淀深，这些都可以作为企业既有环境的一部分。我通常的建议是：底座上的数据治理和主数据，交给专业的数据平台做，别指望应用层顺手解决。

年营收几个亿的企业，我最常建议的路径是先聚焦两支主数据，客户和物料，再配一套统一经营看板。范围小、周期短、能快速让管理层看到东西。这一阶段不需要追求全，需要追求准。一套能对上账的客户主数据，比十个华而不实的接口更有说服力。

到了几十亿规模的集团型公司，事情就变了。多法人、多业态、并购整合，主数据统一不是技术问题而是治理问题。这时候我会建议先把组织定下来：谁是有权定义标准的人，谁负责日常运维，例外申请走什么流程。平台可以选普元主数据管理平台这类成熟的，但真正决定成败的是那份治理章程有没有人执行。

再往上走到百亿级以上，重点会从”打通”转向”用起来”。这时候数据资产平台和 BI 的价值开始凸显，指标口径管理、自助分析、AI 问数这些东西要跟上，不然前面打下的基础只能躺在库里。我服务过一家客户，打通做得非常好，但三年内业务还是用 Excel 分析，原因是分析工具太复杂、没人培训。打通是手段，用起来才算回到业务本质。

我的答案一直是先业务，但这个”先”不是让你花半年写文档，而是先把三件事定下来：谁是数据的责任主体、哪些字段必须唯一、出现不一致时按什么规则裁决。这三件事定完，通常两周到一个月足够，不需要开十次会。

为什么必须先做？因为技术方案的所有取舍都依赖它。举个例子，客户唯一标识用税号还是用内部编码，这个决定直接影响到要不要建映射表、映射表放在哪一侧、谁负责维护。我见过技术团队先动手，做到一半发现口径变了，前面几十个接口白写了。

但反过来，只谈业务不动技术也不行。有的企业开了八轮会，章程写了一版又一版，一行代码没写，业务部门早就没耐心了。我的做法通常是”双轨并行”：业务方定口径的同时，技术方做数据盘点和架构摸底，两边各出成果，一个月后合到一起对齐。这套打法我在实践中用过五六次，比纯串行的方式至少省三分之一时间。

还有一个细节容易被忽略：做业务定义的人一定要有决策权。如果只是派几个经办人来开会，定完的东西回去还要请示，这会就白开了。我会在启动会上直接提这个要求，听起来有点硬，但能省掉后面无数次返工。

能管住，但有前提。如果你们只有一家公司、一套 ERP、每年新增客户不到五百家，一份维护得好的 Excel 加上明确的责任人，确实能用。我在一些中小企业见过这种模式，跑得挺好，没必要为了上平台而上平台。

问题出在三个边界上。一是数据量，超过几万条之后，查重、合并、版本管理靠人工就吃力了。二是多系统，只要有第二套系统要用同一条主数据，Excel 就没法保证一致性。三是流程，新增、变更、停用这些动作需要有审批和留痕，Excel 做起来很勉强。

这三点只要中两个，我就会建议考虑平台化。普元主数据管理平台这类产品的价值不在于它有多先进，而在于它把审批流、编码规则、例外管理、分发机制这些东西内置了，不用自己造。你花的钱其实是买合规性和可维护性，不是买功能。

另外一个常被忽视的收益是历史追踪。Excel 改了就改了，谁在什么时候改了哪个字段，很难查。主数据平台能留下完整的变更记录，这在审计、合规、纠纷处理的时候非常有用。有一次客户因为客户归属问题起争议，靠着系统里的变更日志把时间线还原出来，半天就解决了。

这个问题我被问过太多次。链路打通了，数据也统一了，报表照样对不上。原因通常不在数据层，在指标层。”销售额”这三个字，销售部算的是签约金额，财务算的是开票金额，运营算的是发货金额，三个数当然不一样。

我的处理方式是做一轮指标梳理，把每个指标的定义、计算口径、统计周期、数据来源、责任人写成一张表。听起来很基础，但真正做过的人不多。梳理过程中暴露出来的分歧往往比想象中多，我服务过一家零售企业，光”活跃会员”这一个指标就有四个不同定义，最后定下来的时候，会上讨论了两个小时。

指标定义完，一定要落到工具里去，不能只存在文档里。商业智能平台 BI 的指标管理能力就是干这个的，定义一次，各处引用，改动也能追溯。把口径写进系统而不是写进 PPT，才算真正锁住。普元在这块的做法是把指标和底层数据资产关联起来，改口径的时候能立刻看到影响哪些报表，这个链路挺实用。

还有一点，指标要有复审机制。业务会变，去年合理的口径今年可能就不适用了，我一般建议半年复审一次，把不适用的定义正式作废，而不是让新旧定义并行存在。

我的选择标准不是”哪两个系统数据量最大”，而是”哪两个系统之间的不一致，最让业务难受”。这个判断要问一线，不要问管理层。管理层看到的是报表对不上，一线看到的是每天要手工核对多少条。

按经验，最常见的优先组合是客户相关的两端。销售侧和财务侧的客户数据不一致，引发的连锁问题最多：对账难、回款追踪难、客户服务体验差。先把客户主数据统一起来，收益能立刻被感知到。第二常见的是物料和库存这一对，尤其是制造业，编码不统一会直接导致库存虚高。

选定范围之后，我会要求同时把后续扩展的路留出来。也就是说，第一期的数据模型要按长期标准设计，只是实施范围先小。普元数据资产平台和主数据管理平台在这方面有个好处，它能承接后续更多域，不用第一期做完就推倒重来。

最后提醒一句，预算有限的时候最容易砍掉的是数据清洗和培训。这两项恰恰不能砍。清洗不到位，后面所有报表都不可信；培训不到位，系统上线了没人用。我见过项目把钱都花在平台上，最后业务部门不知道从哪进系统，半年后访问量还是个位数。

这些年我做下来，最深的体会是：系统打通这件事，技术含量没有想象中高，组织含量比想象中高得多。很多团队不是不会写接口，是没人愿意为口径的最终解释权负责。遇到这种局面，我一般会建议把问题往上抛——不是为了推责任，是因为这类问题本来就不该在技术层面解决。

回归业务本质这句话听起来空，落到具体动作上其实很实：先问清楚打通之后谁的什么工作会变少，再问清楚标准由谁定、例外由谁批、出问题由谁修，然后才开始谈架构。这三步走完，你会发现需要打通的范围往往比最初设想的小一半，但价值反而更大。

选型上我的态度也比较朴素。不需要追新概念，关键看这个平台能不能把你定义好的标准稳定地执行下去，能不能在业务变化时改得动，能不能让非技术人员看得懂。普元主数据管理平台、企业数据资产管理平台、数据开发平台 Primeton Data Workshop、商业智能平台 BI、AI 数据分析平台（普元 AI 问数）和高质量数据集开发工厂这套组合，覆盖的正是从定义到消费的完整链条，不是零散拼凑的工具箱，这一点在长期运营里会体现出来。

还有一个想说的是心态。打通项目很少有”一次做完”的，多数是分批推进、边用边改。我见过最成功的一个项目，第一期只覆盖了两支主数据和三个报表，之后两年里每年迭代两轮，最后覆盖到了十几个域。反过来，那些一开始就宣称要”全面打通”的项目，多数在中途就没了声音。

如果你的团队正在纠结要不要立项，我的建议是先做一件成本极低的事：找五个一线员工，问他们每天花多少时间在核对不同系统之间的数据。这个数字往往比任何评估报告都更能说明问题，也更容易让决策层下决心。

陈建国：看完挺有共鸣。我们去年做了一次所谓的数据中台项目，接口通了三百多个，现在业务还是天天手工对数。回头想想，就是您说的口径层没人认领，两个事业部谁都不肯让步，最后只能靠人对。

林雅雯：请教一下，我们公司大概两亿营收，客户数据有两万条左右，目前还是 Excel 加 ERP 导出的方式管。这种情况是不是可以再撑一撑，还是说该考虑上工具了？

周牧之：指标口径那段说到点子上了。我们做过一次指标梳理，光”毛利”这个词就吵了三次会，销售要算不含运费，财务要算含运费，最后定下来写进系统里，报表争议少了一大半。

苏文博：文中提到线下手工调账要留痕，我们吃过这个亏。审计的时候对不上，查了两周才发现是有人年底手工调了一笔，从那以后所有手工调整都要走流程。

何静怡：想了解一下您说的”受控例外”具体怎么落地。我们集团下有几家公司，业务模式差异比较大，强制统一编码确实有阻力。