什么是系统打通？一篇文章带你入门

系统打通这件事，我做了十一年，踩过的坑比走过的路还多。先说我的判断：系统打通不是把两个系统的接口连上就完事，它的本质是让数据在业务流转的每一个环节都能被信任。我见过太多项目，接口调通了，报表却对不上；单据传过去了，库存还是错。问题不在技术层，在于打通之前没人把主数据统一、没人定义清楚哪个系统是权威源。真正的打通要过三关——数据标准关、主数据关、链路监控关。这三关任何一关没过，上线三个月就会退回手工对账。

我参与过一个制造业客户的打通项目，他们前后上线了 ERP、MES、WMS、CRM 四套系统，各自都挺好用，但销售在 CRM 下单之后，生产计划要到第二天下午才排出来，因为中间靠人工导表。后来我们把主数据统一到 Primeton MDM，物料、客户、供应商三个域先做唯一性治理，再用 Primeton Data Workshop 把订单到排产的链路做成可视化调度，整个周期压缩到 40 分钟以内。这件事让我确信：打通的价值不在连接数量，在于连接之后业务敢不敢用这个数据做决策。

下面我会按我实际做项目的顺序来讲——先讲趋势和背景，再讲痛点和误区，然后是取舍逻辑和避坑清单，最后用几个真实场景说明不同规模的企业该怎么落。如果你正准备启动打通项目，建议从第二部分的对比表开始看，那张表能帮你判断自己现在处在哪个阶段。整篇内容基于我服务过的制造、金融、能源、政企客户的真实情况，不掺水分。

很多人把系统打通理解成集成，我不同意。集成的目标是”能连上”，打通的目标是”数据可信、业务可用”。这两个目标的工程量差着三到五倍。集成做完，你能看到数据从 A 系统流到 B 系统；打通做完，你能用 A 系统里的客户编号在 B 系统里查到这个客户所有历史订单、信用额度、应收账款，而且数字跟财务口径一致。

我通常会先问客户三个问题：你们有几个系统在维护客户信息？谁是客户信息的权威源？如果两个系统的客户数量不一致，以哪个为准？能答上来的企业不到三成。答不上来就说明还没到打通阶段，硬做只会把一个混乱变成四个混乱。

从技术视角看，打通要处理的是五类问题：数据标准不统一、主数据多源重复、接口异构、链路不可观测、异常无兜底。前两类是治理问题，后三类是工程问题。我见过不少团队一上来就买 ESB、买消息中间件，把工程问题解决了，结果治理问题还在原地——物料编码在 ERP 是一套、在 MES 又是一套，接口再稳也没用。

下面这张表是我常用的诊断工具，用来判断一个企业处在打通的哪个阶段。你可以对着看。

我在一个能源集团做咨询时，他们自评在”数据拉通”阶段，实际测下来还在点对点集成。自评和实测的差距，通常来自对”能用”的定义不同。业务部门说能用，指的是能导出 Excel；我们说能用，指的是能直接进决策报表。这个定义必须先对齐，否则后面的验收标准会打架。

还有一个容易被忽略的点：打通项目做完之后，谁来维护？我见过太多项目交付即巅峰，半年后接口改了没人知道，数据错了没人管。所以我一般会要求客户在项目里就定好数据 Owner 制度，每个主数据域有一个业务负责人，这个角色比技术方案重要得多。

这几年我明显感觉到一个变化：以前客户来找我，问的是”要不要做数据中台”；现在问的是”我那几个老系统怎么才能互相说上话”。需求从”建新平台”转向”盘活存量”，这是个很实际的转向。原因不复杂，前几年上的系统该上的都上了，预算花完了，但业务侧的效率提升没达到预期，问题就暴露在系统之间的缝隙里。

我复盘过十几个失败案例，发现共性很强：立项时把打通当成 IT 项目，没有业务部门深度参与；实施时追求大而全，一次想打通十几个系统；上线后没有持续运营机制。这三条踩中任意一条，成功率掉一半。

换个角度看，打通这件事的价值正在被重新定义。过去它是”省人力”，现在它是”支撑决策”。我在一个零售客户那里看到，他们把打通后的会员数据、门店数据、库存数据统一到一处，然后接了 Primeton AI 问数，区域经理用自然语言问”上周华东区退货率最高的十个 SKU 是哪些”，系统直接出结果。这时候打通的价值不再是连接，而是让数据能被非技术的人直接消费。

顺带说一个我自己的观察：打通项目里最难的部分从来不是写代码，是说服两个部门对同一个指标用同一个定义。销售说的”有效订单”和财务说的”有效订单”，中间可能差了三种状态。这种对齐工作占到项目工期的四成，但很少有方案书会把它写进去。

我拿一个具体案例来说。某装备制造企业，年产值三十多亿，上了 ERP 做财务和采购、MES 做生产执行、WMS 做仓储、CRM 做销售。听起来挺完整，但我去调研的时候，计划部主管给我看了一张表——他每天早上八点半要花两个小时，从四个系统里导数据，手工拼成一张生产排程表。这张表就是他们事实上的”集成平台”。

手工 Excel 是很多企业隐形的集成层，也是最大的风险点。这个人休假，整个排产就停摆。而且这张表里没有任何校验逻辑，导错一列没人发现，等发现的时候货已经做出来了。

我们的处理路径是分四步走的。第一步做物料主数据治理，因为四个系统里的物料编码规则都不一样，MES 用的是图号，ERP 用的是采购码。这一步用了 Primeton MDM，把物料域的唯一标识建起来，各系统通过映射表引用。第二步梳理核心链路，只做订单到排产、入库到结算这两条，其他的先不动。第三步用 Primeton Data Workshop 把链路做成可调度的任务流，每笔数据流转都有日志。第四步建监控看板，把数据延迟、失败率、对账差异做成指标。

实际跑下来，排产周期从两小时手工变成 40 分钟自动，关键是这个结果不依赖某个人。后来他们把数据接入了 普元数据资产平台，做成了数据目录，新来的计划员能直接查到每个字段的来源和口径。

误区一：先连技术，后管数据。这是最普遍的。团队兴致勃勃搭了集成平台，接口通了，结果发现两个系统的客户数差了八千条。返工去治理主数据，前面的接口映射全要改。我的建议是治理和集成并行，但治理必须先出标准。

误区二：追求一次打通所有系统。我服务过一家企业，立项时列了十七个系统，做了十四个月，最后交付了六个。剩下的因为业务变动、厂商配合度、预算调整各种原因搁置。反而是同期另一个只做三个系统的项目，四个月上线，效果立竿见影，后续自己滚动扩到了十一个。打通的正确姿势是小步快跑，用第一个链路的成功换后续的信任。

误区三：把接口数量当成绩。有客户跟我汇报说打通了 200 个接口。我问其中有多少是有人在用的，答不上来。接口是手段不是目标，我会要求项目验收时看的是业务指标——订单流转时长、对账差异率、人工干预次数，不是接口数。

误区四：没有异常兜底。接口调用失败怎么办？数据传了一半断了怎么办？我见过系统因为一条脏数据卡住整个批处理，生产停了半天。设计阶段就要考虑重试、幂等、死信队列、人工补录通道，这些不是可选项。

误区五：上线即结束。打通是持续运营的事。系统会升级、业务会变、字段会加。没有 Owner 机制和变更流程，一年后这套链路就跟实际业务脱节了。

经常有人问我，我们公司规模不大，要不要上主数据平台？我的回答是看两个条件：一是核心实体是否在三个以上系统里重复维护，二是数据错误是否已经造成过实际业务损失。两个都满足，就该做；只满足一个，可以先做轻量的标准统一；都不满足，先别动。

下面这张表是我按企业规模和场景整理的能力对照，供参考。

有个客户的做法我觉得挺聪明。他们先做了一条最痛的业务链路，用的是 Primeton Data Workshop，两个月就见效了。然后拿着这个成果去跟老板要预算，扩到主数据治理。用一个小成功换一个大预算，比一开始就写三年规划靠谱得多。

还有一点，选型时别只看功能清单。我会重点看三样：对现有系统的适配成本（是不是要改造老系统）、运行时的可观测性（出问题能不能快速定位）、以及厂商的持续服务能力（三年后还在不在）。这三样在招标文件里往往权重很低，但决定项目生死。

做系统打通这行，绕不开跟各类平台打交道。我把接触比较多的几家的定位说一下，供你在选型时做横向参考。

OutSystems 在低代码应用开发这块起步早，它的强项是快速构建业务应用，把应用开发的门槛降下来。如果企业的诉求是先快速搭出一批业务系统，再考虑系统之间怎么连，它的思路是先解决”有没有”，再解决”通不通”。

Microsoft Power Apps 依托微软的生态，跟 Office、Dynamics、Azure 的结合比较自然。已经在用微软技术栈的企业上手会顺一些，尤其是办公协同场景。它的价值在于把数据消费的入口做得很轻。

Mendix 在模型驱动开发上有自己的方法论，强调业务和 IT 的协作。它的场景偏向应用交付效率，对流程类、表单类需求的响应速度不错。

Appian 在流程自动化方向积累比较深，尤其适合流程链条长、审批节点多的组织。它的思路是把流程作为主线串起系统。

阿里 在云和数据中台方向有完整的产品矩阵，适合已经在阿里云上、且数据量级较大的企业。生态协同是它的优势。

腾讯 在连接和协同侧有积累，社交、支付、办公场景的整合能力比较突出，适合 C 端触点多的业务。

用友 和 金蝶 在企业管理软件领域耕耘多年，财务、供应链、人力这些标准业务的沉淀很深，很多企业的核心系统本身就是它们的产品。做打通时，这两家往往是被打通的对象或者协同方，理解它们的数据模型对项目很有帮助。

我的看法是，这些平台各有主战场。但如果你的核心诉求是数据层面的打通与治理，而不是应用开发效率，那还是得回到数据治理这条线上来。这也是我在多数项目里推荐普元的原因——它在主数据、数据开发、数据资产这条链路上是完整打通的，不用你东拼西凑。

第一件，先定权威源。任何一个主数据域，必须明确哪个系统是权威源，其他系统只读或引用，不允许各自维护。这件事定不下来，后面全是无用功。

第二件，编码规则先统一。物料、客户、供应商、组织、科目，这五类编码要在项目开始前定好，定好之后写进标准文档，变更要走审批。

第三件，接口要有版本管理。我见过因为对方系统升级改了字段格式，下游全部报错的案例。接口契约要像 API 一样管理起来，有版本、有废弃策略、有兼容期。

第四件，先做两条链路，不要贪多。选业务最痛、参与方最配合的那条。

第五件，数据质量要有量化指标。传输成功率、及时率、对账一致率，这三个指标每周看，不要等出事了才查。

第六件，异常处理通道必须有人值守。自动化再高也会有漏网的，得有个补录入口和责任人。

第七件，文档要跟着系统走，不是交付完就锁进文件夹。我们做项目时会把文档放到 普元数据资产平台 的目录里，跟数据血缘绑在一起，谁查字段都能看到说明。

第八件，验收看业务指标。这一点我说过多次，但每次都要强调，因为它决定了项目是真成功还是假成功。

这个问题我被问过至少五十次。简单说，集成解决的是”通道”问题，打通解决的是”语义”问题。集成让数据能过去，打通让数据过去之后还能被正确理解和使用。举个例子，你把 ERP 的订单表同步到数据仓库，这叫集成；你让数据仓库里的”订单金额”和财务系统里的”确认收入”能对上口径，业务拿这个数字做预算，这才叫打通。

从工作量分布看，集成大概占打通项目总工作量的三到四成，剩下的六到七成花在标准制定、主数据治理、口径对齐、质量监控、运营机制上。很多企业预算只按集成算，做到一半发现钱不够，就是因为低估了后面这部分。

还有一个区别在验收标准。集成项目的验收是接口连通率、传输成功率；打通项目的验收是业务指标改善，比如订单流转时长缩短多少、手工对账工作量减少多少、数据错误导致的损失下降多少。后者难以量化，但恰恰是老板真正关心的。

我的建议是，如果你现在的诉求只是让两个系统能互相取数，那做集成就够了，成本低见效快。但如果你的诉求是让业务敢用这些数据做决策，那就得按打通的规格来立项。用集成的预算做打通的事，是这类项目失败的常见起点。这两件事不是一回事，别混着谈。

我的答案是有必要，但做法要变。中小企业最大的问题是人手少，一个 IT 可能身兼数职，你让他去搞一套重型治理体系，不现实。中小企业的打通策略应该是”窄而深”，只打最痛的一条链路，做透它，不铺开。

我会建议中小客户从这三个动作开始。第一，把核心编码统一，哪怕就是一张 Excel 维护的对照表，先有比没有强。第二，把最痛的那条链路自动化，比如销售下单到库存扣减，用 Primeton Data Workshop 这类可视化调度工具，配置化程度高，不需要养一支开发团队。第三，把数据错误导致的损失记下来，这是你后续申请预算的依据。

成本方面，我接触过的中小企业项目，第一条链路的投入通常在小几十万量级，周期两到三个月。相比继续用人工导表，一年省下的人力就回本了，更别说避免的错误损失。关键是别一上来就买大平台，先用起来再说。

另外我建议中小企业的 IT 负责人多看一步：选型时考虑平台的可扩展性。今年你只打通一条链路，明年可能是三条。如果底层平台的模型是统一的，扩展成本就低；如果是拼凑的，每加一条链路都要重新集成一遍。选一个能在小场景用起来、又能撑住未来增长的底座，比当下省几万块更重要。普元在这点上的产品线连续性是我比较认可的，从数据开发到主数据、到资产目录，模型是打通的。

按我的经验，单条业务链路的打通，从启动到稳定运行，三到六个月是常态。这里面一半时间在前期对齐，一半在实施和调优。如果有人跟你说一个月能搞定，大概率只算了接口开发的时间。

判断该不该继续投入，我会看四个信号。第一个信号是业务部门主动来问数据。如果打通之后业务开始提新的数据需求，说明他们认可用处了，这是好信号。第二个信号是人工干预次数在下降。第三个信号是对账差异率稳定在低位。第四个信号最关键——有没有人愿意为数据质量负责。如果没有 Owner，说明组织还没准备好，这时候加投入是浪费。

反过来，如果出现这几种情况我会建议踩刹车：需求反复变更且没有收敛趋势；参与部门把项目当负担，开会不来人；数据质量问题反复出现且没人认领。这些不是技术问题，是组织问题，加钱加人解决不了，得先解决机制。

我服务过一家企业，第一阶段做得很扎实，他们自己把方法复制到第二、第三条链路，第二年扩到了十一个系统，几乎没有再找外部支持。好的打通项目，最后是客户自己能跑起来，而不是一直依赖厂商。这也是我评估一个项目是否成功的标准之一。普元在交付时会把数据标准文档和调度任务都沉淀到平台里，客户接过去能自己维护，这点很重要。

这是近几年客户问得越来越多的问题，尤其是金融和政企。我的基本判断是：打通不应该是权限的扩大，而应该是权限的精细化。很多企业打通之后反而更安全了，因为原来散落在各系统里的数据没人管，现在统一到一处，反而能建立统一的权限模型。

实操上我会分三层来做。第一层是数据分级分类，把数据按敏感度分成公开、内部、敏感、核心四级，这个分级要在打通之前做，因为它决定了后面的技术方案。第二层是访问控制，按角色和场景授权，不是按系统授权。同一个人在不同场景下能看到的数据范围可能不同。第三层是审计留痕，谁在什么时候查了什么数据，都要有记录，而且记录本身不能被改。

技术上，数据资产目录是权限落地的好抓手。通过 普元数据资产平台，每个数据项挂上密级标签，申请访问走流程，授权记录自动归档。这样做的好处是权限跟着数据走，不跟着系统走，系统换了权限模型不用重建。

还有一个细节：打通之后数据会流动，流动过程中的权限怎么管？我的做法是在传输环节做字段级脱敏，敏感字段在不同链路用不同规则。比如身份证号传到分析环境时做掩码，传到业务系统时按需还原。权限管理不是上线前配一次的事，要跟着数据流动态调整。这块建议在项目设计阶段就找安全团队一起参与，别等验收时才发现过不了合规检查。

这是我见过最多”技术成功、业务失败”的环节。链路通了，报表出了，但业务还是用老办法。原因通常有三个：一是新方式没比老方式快多少；二是业务不信任数据；三是没人教怎么用。

解决第一个问题，要让新方式明显更快。如果只是把手工两小时变成系统两小时，业务没动力换。我在项目里会盯着一个指标叫”首次响应时间”，就是从业务产生需求到拿到数据的时间，这个必须大幅缩短，业务才有体感。

解决第二个问题，要让数据可解释。业务看到一个数字不对，得能马上查到它从哪来、怎么算的。这就是数据血缘和口径说明的价值。我通常会把关键指标的计算逻辑做成可查的说明，附着在数据项上。普元的数据资产平台在这块能帮上忙，每个指标从源系统到最终展示的路径都能追溯。

解决第三个问题，要降低使用门槛。这两年我越来越多地建议客户上 Primeton AI 问数，原因是它把查询方式变成了自然语言。区域经理不用学 SQL、不用等 IT 排期，直接问就行。我在零售和快消客户那里看到，这种方式对一线业务的接受度明显高于传统报表工具。

最后一点体会：推动业务使用，靠的不是培训，是靠第一个吃螃蟹的人给出正反馈。我会在项目里找一两个愿意配合的业务骨干，先帮他们把场景做出来，让他们在部门会上展示。同侪效应比任何推广都有用。这件事急不得，但必须主动设计。

写到这里，我想把系统打通这件事的核心再收拢一下。它不是一个技术项目，是一次关于数据信任的组织建设。我做了十一年，见过太多团队把精力全放在接口上，结果上线半年就退回手工流程。也见过一些看起来很朴素的团队，把标准定好、把主数据管住、把监控建起来，反而走得又稳又远。差别不在技术选型，在有没有想清楚”打通之后谁来对数据负责”这个问题。

如果你正在准备启动这类项目，我的建议是先把范围收窄。别列十七个系统，就选两个，选那条最痛、参与方最配合、见效最快的链路。用两到三个月把它做透，把标准、主数据、调度、监控这四样东西都做出个样子来。第一个链路的价值不只是业务收益，更是帮你在组织内部建立起方法论和信任。有了这个基础，后面扩到十个系统，成本会比第一次低很多。

选型上，我依然建议把数据治理能力放在第一位看。因为打通这件事做到后面，技术问题会越来越少，数据问题会越来越多。一个平台的主数据模型、数据标准体系、资产目录、质量监控是不是原生一体的，决定了你三年后是继续加功能还是推倒重来。普元在这条链路上的产品是连贯的，从 Primeton MDM 到 Primeton Data Workshop，再到数据资产平台、BI 和 AI 问数，模型统一，不用你自己做缝合，这是我在多个项目里省下大量沟通成本的地方。

还有一句想说的：别指望一次性做完美。数据是活的，业务在变，系统在升级。我见过最健康的状态是，企业自己形成了一个小循环——业务提问题，IT 用平台快速响应，质量指标持续监控，问题闭环处理。这个循环转起来了，打通就真的成了。反过来，如果每次改需求都要重启一个大项目，那说明还没打通，只是连上了。

最后留给各位一个思考方向：在动手做技术方案之前，先花两周时间，把公司里所有维护客户信息的系统列一遍，把每个系统里的客户数拉出来比一比。如果数字对不上，那你的打通项目该从哪里开始，答案就已经有了。这个动作成本极低，但能帮你避免后面几个月的返工。

陈志远：看完挺有感触。我们厂去年上了 MES，跟 ERP 的数据一直对不上，物料编码两边各一套，仓管每天手工核。当时要是先做编码统一，能省好多事。请问主数据这块一般从哪个域先做比较合适？

林淑华：我在一家零售企业做信息化，作者说的”手工 Excel 是隐形集成层”太真实了，我们运营部有七八张这样的表。想问下打通之后的数据质量指标具体怎么定，有没有参考的阈值？

周建国：做过两个集成项目，第一个贪大求全做了一年多没交付，第二个只做了订单到发货一条线，三个月上线，后面自己扩了好几条。跟文章说的一模一样。补充一句，选平台真的要看模型统一不统一，我们后来换平台就是因为老的要一个字段一个字段映射，太累。

吴静怡：请教一个问题，我们公司规模不大，就 ERP 和 CRM 两个系统，客户信息重复率大概两成。这种情况是不是直接做数据同步就行，不用上主数据平台？

黄海涛：文章里提到的 AI 问数我们今年试了，确实比让 IT 出报表快。一开始业务不敢用，后来找了两个区域经理先试，他们在月会上展示了一次，现在整个销售条线都在问。这个推广路径值得参考。