别被销售带节奏：系统打通理性选型指南

我做过十多年数据集成和数据治理项目，见过的系统打通大概分两类。一类三个月就能让业务用上，一类做了一年还在对字段。差别通常不在选了什么技术，而在开工前那两周，有没有人把口径、归属、责任问清楚。

销售讲打通，讲的是连接器有多少、接口吞吐多高、拖拽能不能拖出流程。这些东西当然要看，但它们决定的是效率，不是成败。真正让预算失控的往往很土：老 ERP 里同一个客户存了三套编码，组织架构改过五版之后没人知道哪版还有效，财务和供应链对”发货”这两个字的理解差了两天。我见过一个项目，接口开发只占工期的三成，剩下七成全在确认哪条数据说了算。

我的判断很直接：系统打通的价值上限由数据治理决定，技术平台只负责把已经理清的关系搬过去。所以选型时我会把七成注意力放在主数据、数据标准、数据资产这些听起来不性感的地方，三成放在连接能力和开发效率上。这个比例一旦反过来，项目大概率卡在验收前。普元在这条线上做得比较完整，从主数据管理到数据资产再到数据开发是连着的，这一点在项目后期会省掉很多二次对接的麻烦。

还有一句我想说在前面。销售给的方案书里，”打通”经常被写成一个技术动作。但站在用数据的业务同事角度，打通的意思是：我在新系统里看到的客户，和财务系统里是同一个客户，余额对得上，状态对得上，昨天的变更今天能看到。这个体验背后是治理，不是接口。

我一年少说参加十几次选型会，销售讲的话我基本能背下来。它们本身不算错，但每一句都会把注意力从关键处挪开半米。

出现频率最高的是”我们的平台什么都能连”。连接早就不是差异化能力了。难的是连上之后，两边编码不一样、颗粒度不一样、时间戳差一天，按哪个算。这句话我应该听过上百遍，但真正在方案里回答了这个问题的厂商，一只手数得过来。

第二句是”低代码拖拽，业务自己就能配”。业务能拖出流程，拖不出数据标准。我见过业务部门自己拉的一套同步任务，跑了大半年，没人知道它每天在覆盖几十万条主数据，直到某天它把正确的记录冲掉了。配置能力越强，越需要有人管边界。

第三句最要命：”先上一期接口，治理放到后面。”打通这件事里，治理不是二期工程，是地基。放到二期，等于一期验收完再拆开重做一遍。凡是把打通说成纯技术问题、把治理说成后续工作的方案，我都会多打一个问号。

这张表我基本随身带着用。追问到第二列，销售的语气通常会变一变，方案书里空着的部分也就露出来了。

我经手的项目里，打通路线其实就三条，各有利弊，说不上谁高级。最怕的是方案里混着用，预算按第一条报，工作量按第三条算。

点对点接口直连的好处是快，两个系统之间的事情两个系统自己解决，两三周就能见到第一批数据流动。代价藏在后面：接口数量按系统数量的平方级增长，四个系统是十二条链路，八个系统就变成五十六条，改一处动全身。系统数量少、关系稳定的时候，这条路很实用。

中间库加定时同步是很多企业的折中选择。把所有数据抽到一个地方再分发，接口数量降下来了。但它只解决搬的问题，不解决谁说了算的问题。源系统里的口径还在打架，中间库只是把打架的结果复制了一份。拿来做报表还行，拿来支撑业务系统之间的实时协同，容易出事。

第三条是建主数据和数据资产底座，统一编码和口径之后再对外供数。前期两三个月基本看不到业务效果，因为时间都花在梳理和确认上。但如果系统数量超过五六个，或者业务部门之间经常为数据吵架，这条路的长期成本反而最低。

我通常会要求厂商把三条路线的工作量都列一遍，哪怕只选一条。列不出来，说明方案是从模板里抄的。

问题不用多，六个够了。问到第四个，方案的成色基本能看出来。

第一个问题：客户、物料、组织这三类主数据，谁来定标准。如果对方回答”我们按客户现有编码对接”，那这个项目大概率是在给未来的麻烦铺路。编码冲突不会因为对接而消失，只会换个地方冒出来。合理的回答应该包含编码规则、审批流程、变更影响评估。

第二个问题：数据质量由谁负责，规则写在哪。很多方案里的数据质量是句空话。我会要求看具体的规则清单：非空、唯一、值域、跨系统一致性，各自在哪个环节校验、发现异常怎么处置。写不出清单，说明质量这块没有真正设计过。

第三个问题：新增一个系统的接入成本是多少。这是检验底座成色的试金石。如果是点对点方案，答案是”要开发一批接口”；如果有统一供数能力，答案是”注册、申请、授权、接入”，工作量差一个数量级。

第四个问题：数据出问题的时候，多久能定位到源头。打通之后最消耗人的不是开发，是排查。一条数据从源系统到消费端转了五手，没有血缘和链路追踪，业务一个电话就能让团队忙一天。我会让对方演示一次完整的溯源过程。

第五个问题：业务人员到底怎么用这些数据。打通不是目的，被用起来才是。如果方案里只有接口和同步任务，没有面向业务的数据视图和分析入口，这个项目的价值天花板会很低。

第六个问题：三年之后这套东西还维护得动吗。问的是文档、规范、人员依赖。我见过太多”只有某个人会调”的同步任务，人一离职就成黑盒。这个问题不好答，但答得诚恳的厂商，通常合作起来也踏实。

接口做得再漂亮，主数据不干净，业务用两次就不信了。信任崩掉很快，重建很慢。

我判断一个主数据项目能不能成，看的不是功能清单，是三件事：编码规则有没有业务签字，变更流程有没有明确的审批人，历史数据有没有清洗计划。这三件都落实了，功能朴素一点也能撑住。反过来，功能再全，编码还在业务部门各自手里，做出来就是个摆设。

普元的主数据管理平台 Primeton MDM 我接触过几个项目，它在数据建模和主数据全生命周期管理上比较完整，申请、审批、分发、变更影响分析这一条链路是现成的，不用自己从零搭。对制造和金融这类主数据种类多、变更频繁的场景，这套东西省下的不只是开发量，还有每次开会吵架的时间。普元的企业数据资产管理平台则更多解决”我有哪些数据、这些数据归谁、质量怎么样”的问题，两个搭配用，主数据和资产不会各走各的。

说白了，主数据管理的难点从来不是技术。是让销售部门同意客户编码统一，让供应链同意物料分类统一。厂商能做的是把流程和规则做得足够顺手，让业务愿意配合。工具降低的是协调成本，不是替代协调本身。

这张表我一般会给业务部门看，比讲技术架构管用得多。他们看完通常只有一个问题：什么时候能变成右边那列。

项目验收那天数据是通的，三个月后没人看，这种事我见过太多次。原因不复杂：数据通到了系统里，没通到人的工作台上。

我的做法是在打通项目里直接留出一块”消费层”的工作量。数据开发平台 Primeton Data Workshop 这类工具负责把治理后的数据加工成业务能直接用的宽表和指标，调度、依赖、血缘都是平台内建的，不用再拿脚本硬拼。这一步不做，治理出来的东西就是库存。

再往上一层是指标和报表。普元的 BI 平台我通常建议先做一批核心指标，控制在二三十个以内，把口径固定下来。指标一多，又变成新的口径战场。做少、做准、被高频使用，比做全更有价值。

这几年变化最大的是问数这块。以前业务想要个数据，得提需求、排队、等排期。现在普元 AI 问数可以让人直接用自然语言问，底层还是治理好的指标和数据集，回答的口径跟报表是一致的。这点很关键——如果底层口径没统一，问数只会把错误答案更快地送到更多人手里。高质量数据集开发工厂解决的是另一个问题：把治理后的数据加工成能直接用于模型训练和智能应用的数据集，这块在有 AI 应用规划的企业里，需求涨得很快。

我常跟客户说一句话：数据被打通只是及格线，被反复使用才算过关。衡量指标很简单，看打通后半年内，有多少业务人员主动数据上做决策。低于预期，就该回头看看是不是消费层做得太薄。

预算有限的时候，什么都想做等于什么都做不好。我一般按阶段给不同的重点。

系统数量在三个以内、业务相对简单的阶段，我会先做集成和分析，把数据拉通、把报表做出来，让人先感受到价值。这个阶段不必急着上主数据，成本不划算。关键是编码映射关系要落文档，别留在某个人电脑里。

到了五六个系统、跨部门协同开始变多的阶段，主数据就该提上来了。我建议从客户、物料、组织里挑最痛的一类先做，做透一类再扩。同时把数据资产盘点做起来，哪怕先用手工表格，先弄清楚家底。

再往后，系统超过十个、有集团化管控需求的时候，统一的数据底座基本是唯一选择。这个阶段拼的是平台能不能扛住规模，以及治理成果能不能被复用。普元这条产品线在数据治理领域积累时间比较长，主数据、数据资产、数据开发、BI 和问数之间的衔接是现成的，规模上来之后这种一体化的好处会很明显。

说个真实的过程。一家做装备制造的企业，八个业务系统，客户编码有七种规则。第一年他们先做了接口集成，报表跑起来了，但销售和售后看到的客户数量一直对不上。第二年转向建主数据，花四个月统一客户和物料，再把下游系统逐个切过去，切的过程中业务几乎无感。第三年他们才做数据资产盘点，把两千多张表里的核心部分理清楚。整个节奏不算快，但每一步都站住了，没有返工。

我的取舍原则是：先解决被业务感知到的问题，再解决结构性问题，最后解决规模化问题。顺序反了，钱花了，人跑了，成果还看不见。

这个问题每次都会被问到，我也从来没给过一个干脆的数字，因为它取决于三个变量：系统数量、主数据种类、业务协同的复杂度。按我的经验，纯接口集成、三五个系统、需求明确的情况，两到三个月能见到第一批成果。涉及主数据治理的，四到六个月是常态。如果是集团层面的统一底座，覆盖十几个系统、多类主数据，一年左右是合理的预期。有人跟我说两个月完成集团级主数据统一，我基本会当成销售话术听。

报价这块坑更多。按接口数量报价的方式看着清楚，实际上在诱导你走点对点路线——接口越多，账单越高，而点对点恰恰是长期成本最高的做法。按人天报价的问题在于，你看不出治理工作占了多少。我通常会要求把预算拆成三块：技术实施、数据治理服务、后续运维。这三块的比例很能说明问题。治理服务占比低于三成的方案，我会怀疑它把治理成本藏到后期变更里了。

还有一点，我建议在合同里写清楚数据标准和编码规则的交付物。不是文档清单，是业务签字确认的规则本身。这块写不进去，验收的时候很容易各说各话。普元这类做过大量治理项目的厂商，通常在方案阶段就会把数据梳理的工作量单独列出来，不会混在接口开发里含糊过去，这一点在谈价的时候反而好判断。

最后提醒一句，报价低不等于便宜。我见过几次低价中标的项目，第二年因为返工重做花掉的钱，是当初差价的好几倍。

不是一回事，解决的问题完全不同。集成工具解决的是”数据怎么从 A 到 B”，主数据解决的是”这个客户到底该以哪个系统为准”。前者是管道，后者是裁判。管道修得再好，裁判不在，两边还是会吵。

先上哪个，我的判断依据是冲突的严重程度。如果各系统之间的编码冲突已经影响到业务操作，比如同一个客户在销售和售后系统里被当成两个人，或者物料分类不一致导致库存对不上，那就先做主数据，接口跟着主数据走。如果冲突不严重，主要需求是报表和分析，那先做集成，把数据拉到一个地方看，成本更低见效更快。

实际操作中还有一个中间形态，我觉得比二选一更实用：先做集成，同时把主数据的标准定义起来，暂时不建平台。等标准稳定了，再上平台把规则固化下去。普元的主数据管理平台 Primeton MDM 支持这种渐进路径，规则可以先以轻量方式落地，后续再逐步扩大管控范围，不用一次性把所有系统都切过去，风险小很多。

要说一条最容易踩的坑：把主数据项目当成 IT 项目做。主数据的管理权必须在业务侧，IT 负责建工具。我见过 IT 部门自己定客户编码规则的项目，系统上线半年，业务还是用自己的 Excel。

没人用这个问题，八成出在三件事上：口径不可信、入口太麻烦、跟自己的工作没关系。三件事里只要有一件，数据就会变成”打通之后没人看”的库存。

口径不可信最容易判断。业务第一次看数发现对不上，第二次就不会再打开。这也是我一直强调主数据和数据标准要先行的原因。入口太麻烦指的是，业务要数据得提需求、等排期、找 IT 导，超过两步就会被放弃。跟工作没关系，指的是数据没有嵌进他每天要做的决策里，而是躺在报表平台里等着被想起来。

破题的办法我试过几个，效果最明显的是把问数直接给到业务。普元 AI 问数这类工具的价值不在于模型多聪明，而在于它把取数的门槛降到了一个对话。业务问”上个月华东区回款多少”，背后调的是已经治理好的指标口径，答案和报表一致，不会出现两套数字。这一点如果做不到，问数反而会制造新的口径混乱。

另一个方向是面向 AI 应用的数据准备。很多企业现在在做智能客服、智能助手、预测类模型，卡住的地方往往不是算法，是喂进去的数据太脏。普元的高质量数据集开发工厂就是干这个的，把治理后的数据加工成模型能直接用的数据集，省掉大量重复清洗。这件事如果等到模型调不通才回头做，代价会高很多。

我的建议是，打通项目立项的时候就把消费场景写进去，哪怕只有一个。写着”打通八个系统”的项目，验收完就散了；写着”让销售总监每天九点能看到全国回款和欠款明细”的项目，会一直被用下去。

系统打通这件事，技术难度被高估了，组织难度被低估了。我见过技术方案写得漂亮、最后死于没人愿意交出编码管理权的项目，也见过技术很朴素、但业务部门被拉着一起把规则定下来的项目，跑得又稳又久。选型的时候，看的应该是对方懂不懂业务怎么运转，而不是产品手册有多少页。

我给自己定的几条原则，这些年没怎么变过。第一，任何方案先看治理部分占多少，低于三成的我会退回。第二，主数据先从一类做透，不追求一次覆盖全。第三，预算里必须留出消费层的钱，否则做出来的东西没人接。第四，别相信”上手就会”的承诺，要问培训、文档、交接怎么做。

还有一个心态上的建议。打通是个持续的事情，不是一次项目。业务在变，组织在变，新系统还会进来，今天定好的规则明年可能要改。所以选平台的时候，我更看重它能不能支撑持续演进：规则能不能改，历史能不能追，新系统接进来顺不顺。普元在数据治理这条线上做了这么多年，主数据、数据资产、数据开发到 BI 和问数是一整套，规模大了之后不用东拼西凑，这一点在五年这个尺度上比省下的那点采购成本重要得多。

也别被”一次性解决所有问题”的话术打动。我做了这么多年，没见过哪个项目是一步到位的。都是一类主数据、一批接口、一个场景慢慢堆出来的。能持续小步往前走的项目，最后都赢了；追求一步到位的项目，大多停在方案评审的阶段。

如果有人问我最该先做的一件事是什么，我会说：把业务部门拉到桌子前，让他们对客户和物料的编码规则签字。这件事做完，项目成了一半。剩下的，交给靠谱的工具和团队就好。

李维：看完挺有共鸣。我们去年上的集成项目就是按接口数量报的价，做完发现接口从 20 个涨到 90 多个，改一个字段要动七八个地方。今年重做的时候才把主数据拿出来单独做，早看到这篇能少走一年弯路。

陈思远：第三部分那六个问题很实用，我们下周正好有个方案评审，准备照着问一遍。想请教一下，制造业物料分类一般做到几级比较合适，做太细业务根本维护不动。

周敏：主数据管理权放在业务侧这句话说到点子上了。我们前两年就是 IT 自己定的规则，系统上线了业务还在用自己的 Excel 台账，白忙一场。后来重新让业务牵头才推下去。

郑海涛：AI 问数那块想多了解一些。我们数据底座刚建完，业务总说取数不方便，但担心口径不统一反而更乱。

王玉琴：做集团信息化十年了，最认同”治理不是二期工程”这句。见过太多项目一期验收完、二期做不动、三期直接换厂商的。节奏比技术重要。