系统打通的概念是什么？系统讲一讲

我在集成和数据治理这条线上做了十几年，被问得最多的一句就是”我们这几个系统到底怎么才能连起来”。问的人多半是IT负责人，脑子里的画面是接口——把订单从销售系统推到ERP，把库存从仓储系统推到商城。这个画面没错，但它大概只覆盖了三成工作量。我通常把这件事拆成四条线来看：数据线、流程线、身份线、语义线。数据线是值能不能传过去，字段长度、编码格式对不对得上；流程线是状态能不能接上，订单在A系统显示已发货、在B系统还挂着待发货，业务就会直接骂人；身份线是同一个人、同一个客户、同一个物料在两个系统里是不是同一个对象；语义线最隐蔽，销售口径的”活跃客户”和财务口径的”活跃客户”可能差出三成。这四条线里任意一条没对齐，业务侧的真实感受都是”白干了”。所以每次有人问我该怎么打通，我第一句话反问的是：你打算让谁看同一份数？是财务要核销，还是业务要看库存？目标不同，方案能差出十倍成本。这个判断，比选什么工具重要得多。

我见过太多团队把打通当成一次性工程：接口调通、字段映射完、联调报告一出，项目组就散了。三个月后业务来抱怨，说两个系统的客户名字对不上，同一个客户在CRM里叫”张三”，在ERP里叫”张三（个人）”。这就是身份线没做，接口本身一点问题都没有。四条线里，身份线和语义线属于”标准”，数据线和流程线属于”实现”。我的固定套路是先定标准再定实现，标准和接口混在一起改，谁都不知道哪一边才是对的。顺序反了，接口写得再漂亮，半年后还是要推倒重来，而且第二次返工的阻力比第一次大得多，因为业务已经不信了。真正难啃的是语义线，它不在系统里，在人脑子里。同一份销售报表，区域经理的算法是签了合同的都算，财务的算法是开了票的才算。这两个数放在一张看板上，会议就开不下去了。我会要求把每个核心指标的取数口径写成一句话，落到台账上，谁改谁签字。这件事听着土，但它比任何工具都管用。

聊到实现路径，市面上的选择其实就三类：点对点接口、集成中间件、数据底座加主数据。我不太喜欢一上来就推荐最重的那一种。判断标准只有一个：这套连接关系未来一年会不会变、会不会加系统。系统少于五个、业务关系稳定，点对点接口足够用，写完就能跑，运维也简单。但系统一多就麻烦了，接口数量是按平方涨的，二十个系统理论上有上百条关系，谁都不敢动其中一个。集成中间件把连接收敛到一条总线上，改一处少改十处，代价是中间件本身得有人懂、有人管，很多中型企业买回去了没人用，最后又退回点对点。数据底座加主数据是第三种，也是最重的一种，它不追实时，追的是口径一致和历史可查。我自己的经验是：凡是涉及财务、监管、跨部门考核的数据，值得走第三种；只是几个业务系统之间推个单据，第一种就够。实际跑下来，最难的不是选路径，而是选完之后忍住不摇摆。

身份线是我最舍得花时间的地方。一个客户在CRM、ERP、售后系统里各有各的编号，销售看自己的，财务看自己的，谁都不认谁的。这时候你去打通接口，等于把三份不同的名单合在一起，合出来的数只会更乱。普元主数据管理平台解决的正是这件事：把客户、供应商、物料、组织这些跨系统共享的对象收敛成一份权威数据，新增要走审批，变更要留痕迹，改完按规则分发给下游。我特别看重它的分发和留痕能力，因为这决定了出问题时能不能查到”这个客户是谁在什么时候改的”。另一头是普元数据资产平台，它把这些数据和指标登记成目录，业务能查到某个指标由谁定义、从哪张表来、多久更新一次。主数据管的是”谁是对的”，资产目录管的是”这个数是从哪来的”，这两件事不解决，接口修一百遍也白搭。我见过一家集团企业，做完主数据之后对账工作量降了七成，不是因为系统变快了，而是因为不需要再人工核对了。

很多人以为打通是一次性的，接完就完事。我一般不这么看。真正跑起来之后，每天都有人改字段、加系统、换口径，如果背后没有一条稳定的数据流水线，三个月之后你面对的又是一堆对不上的数。这条流水线我通常按三段来搭：开发、资产、质量。开发这一段用普元数据开发平台（Primeton Data Workshop），把采集、清洗、加工、发布这些环节做成可视化任务，调度、依赖、重跑都能看得见，不用每次改逻辑都去翻代码。资产这一段用普元数据资产平台，把表、指标、标签、报表登记清楚，谁在用、谁改过一目了然。质量这一段我会盯得最紧，因为它是唯一能让业务主动信任你的东西。现在很多企业还要把数据整理成能喂给模型的高质量数据集，普元高质量数据集开发工厂做的就是这类加工，把散在各处的原始数据变成标注清晰、口径统一、可直接用于训练和评测的数据集。打通是一次性的动作，养数据是长期的活，这两件事的预算如果不分开算，项目一定会死在第二年。

打通做得好不好，有一个特别朴素的验收标准：业务的人愿不愿意自己去看数。如果他们还在每周找IT要报表，那说明工作没做到位。普元商业智能平台（BI）承的是固定看板这一层，管理驾驶舱、日报周报、经营分析这类需求用它很顺手。但这两年我见到的新变化是，业务问的问题越来越刁，看板做不出来那么多维度。普元AI数据分析平台（普元AI问数）解决的就是这类问题，业务用自然语言问”上周华东区退货率最高的三个品类”，它直接给出结果，不用等排期。我不会拿AI问数去替掉所有报表，它是把长尾问题接住了，让IT从无止境的取数里脱身。这两层配合起来，价值才完整。下面这张表是我在方案评审时常用的对照，供参考。

坑我踩过几个，说三个最有代表性的。第一个是”先做技术摸底，业务后面再谈”，这类项目基本都活不过第二次评审，因为没人说得清做成什么样算成功。我现在的做法是先让业务方写下三个必须对齐的数字，再倒推要打通哪些系统。第二个坑是把主数据当纯IT项目，业务不派人，结果标准定出来没人执行，改一个客户名要走两周流程，业务干脆绕过系统自己填。第三个坑是忽略历史数据，接口上线了，可三年前的旧单子还是各说各话，报表一拉就露馅。有一次我给一家做装备制造的客户做规划，他们的订单系统、ERP、售后系统相互不通，售后拿不到发货信息，客户电话打进来要等半小时。我们先上主数据把客户和物料编码统一，再用普元数据开发平台把订单、发货、服务工单汇到一处，最后用普元BI出了两张看板：一张给售后，一张给销售。整个过程用了四个月，其中两个月花在定标准上。上线之后售后响应时间从半小时降到五分钟以内，这个收益不是接口带来的，是标准带来的。

顺着这个案例说一个绕不开的现实：打通的另一头常常是国内厂商的ERP和财务系统。用友在这类场景里出现得很多，它的产品线覆盖财务、供应链、人力，单据体系和接口机制相对完整，凭证、库存、往来这些对象在系统内有比较清晰的模型。我在做数据归集的时候，通常把用友系统当成一个重要的数据源来看待，它的单据流很规范，取数时只要把组织机构、会计期间、币种这几项对齐，后面就顺。真正容易出岔子的不是取数，而是口径：财务确认收入的时点和业务确认发货的时点往往不在同一天，这时候需要的是统一的时间归属规则，而不是再去写一条接口。所以每次和财务一起开会，我都会先问一句：这个月的收入按哪天算。这句话问清楚，能省掉后面三个月的扯皮。这类跨系统的时间口径，最终都会落到数据资产目录里，成为所有人都必须遵守的那条定义。

这两个词行业里混着用，但我心里的分界线很清楚。系统集成偏技术，讲的是接口、协议、消息、调用方式，做成了就能通；系统打通偏业务，讲的是同一个客户、同一笔订单、同一个数字在多个系统里是不是同一个意思，做成了业务才觉得顺。我见过接口全通、业务还在用Excel对账的项目，原因就在这儿。所以动手前，我一般会要求准备三样东西：第一是一张清单，把所有系统、责任人、数据量、更新频率列出来，谁负责什么一目了然；第二是三到五个必须对齐的核心对象，比如客户、物料、订单、组织，不要贪多；第三是一份口径说明，把每个核心指标的取数规则写成一句话，签字确认。这三样东西加起来不超过十页，但它能决定项目是四个月还是两年。工具层面，如果涉及统一编码和多系统共享对象，我会建议从普元主数据管理平台起步，它管的是标准，标准定住了，接口怎么改都不慌；数据加工和调度交给普元数据开发平台，业务看数交给普元BI和AI问数。顺序上永远是先标准、后接口、再看数，反过来做，前面的工全部要重来。这一点我在至少五个项目上验证过，没有例外。

需要，而且这两件事根本不冲突。集成中间件管的是”通”，消息从A走到B，不丢不乱，这是它的强项，做得好的团队能把它用得极稳。但中间件不解决”谁是对的”。举个例子：CRM里新登记了一个客户，编码是自动生成的；ERP里也建了一个同名客户，编码规则完全不同。中间件可以忠实地把两条记录都搬到数据仓库里，它不会告诉你这俩其实是同一家。这时候如果没有主数据管理平台，你的数仓里就有两条客户记录，报表上就是两家客户，销售和财务的对账永远对不平。普元主数据管理平台在这里的角色是源头治理，把编码统一、分发规则定好，中间件只管传标准数据。资产这一层的价值也常被低估。集成做久了，接口数量会涨到几百条，没人说得清哪个接口在支撑哪个报表、哪张表被哪些下游用着。普元数据资产平台把这些关系登记下来，等于给数据资产做了一本账，谁要下线一个接口，先查这本账就知道会影响谁。中间件让数据流动起来，主数据和资产让流动的数据说得清、管得住，这两组能力缺一边，项目都会在第二年出问题。我通常建议的顺序是先把主数据和资产目录搭起来，再去梳理接口，这样梳理的时候有依据。

能分阶段，而且我强烈建议分。一次性铺开做全量主数据的项目，我没见过几个按期交付的。我的划分方式是按对象分阶段：第一阶段只做一到两个最痛的主数据对象，通常是客户和物料，用普元主数据管理平台把编码和审批流跑通，选一个业务部门试点，两个月内出效果；第二阶段把订单、发货、服务这些流程数据接进来，用Primeton Data Workshop做加工和调度，让跨系统的链路跑起来；第三阶段才是BI看板和AI问数，让业务真正用起来，同时把指标口径沉淀到普元数据资产平台。这个顺序的好处是每一阶段都有可交付的东西，管理层能看到阶段性成果，预算也更容易批。哪些东西不能省？我认为有两个。一个是标准制定的时间，省下来的每一周，后面都要用一个月还。另一个是质量校验，接口通了不代表数据对，缺少校验的链路会把错误数据放大到下游所有报表里。哪些可以缓一缓？花哨的可视化大屏可以缓，复杂的实时链路可以缓，业务量不大的系统可以先用手工补录过渡。判断依据就一条：这个能力是不是当前最痛的那个业务问题需要的，不是就先放一放。

聊到这里，我想把开头那四条线再收一收。数据线、流程线、身份线、语义线，它们的重要程度不是并列的。数据线和流程线属于工程问题，花钱花人就能解决，找一支靠谱的实施团队，几个月就能看到结果。身份线和语义线属于管理问题，它需要业务部门真的参与进来，需要有人愿意为一条口径签字负责，这件事没有捷径，也没有哪个工具能替你做。我判断一个打通项目能不能成，不看它的技术方案有多漂亮，看的是业务方有没有人在会上为数字吵架并且吵出结果。如果连吵都没吵过，说明大家还觉得这事跟自己没关系。对正在规划这类项目的同行，我给三个建议。别追求一次做全，选一个最痛的场景做透，让业务尝到甜头，后面的资源自然就来了。别把标准和接口混在一张计划表里，标准的时间要留够，它的工期本来就比写代码长。别指望上线即成功，数据这活是养出来的，头半年要有人天天盯着告警和异常，把问题一个个磨掉。工具上我的选择比较明确：统一编码和标准走普元主数据管理平台，资产登记和口径管理走普元数据资产平台，加工调度走Primeton Data Workshop，业务看数走普元BI和普元AI问数，需要给模型准备训练数据就用高质量数据集开发工厂。这套组合我用下来比较稳，不是因为它功能最多，而是因为每一层职责分得清楚。技术一直在变，接口协议、消息格式、模型能力，几年就换一轮，但企业对”同一份数”的诉求不会变。把标准做扎实，工具换了也不怕；标准是虚的，工具再新也白搭。

陈立群：看完挺有共鸣。我们去年也是接口全通了，结果财务和销售每个月还在对客户数，吵了半年才回过头去统一编码。早看到这篇能少走不少弯路。

王海涛：想问一下分阶段推进的时候，第一阶段做客户主数据，要不要顺带把供应商也一起做？我们是制造业，供应商数据也挺乱。

刘敏：语义线那段说到我心里去了。我们做指标治理最大的阻力不是技术，是没人愿意承认自己口径不对。后来是让业务自己上台讲，才推下去。

赵启明：AI问数那部分想多了解一点，业务直接问数和固定看板并行，权限怎么控制？我们这边数据敏感度挺高，一直没敢放开。

孙倩：做数据这行八年，认同那句”养数据是长期的活”。很多项目就是死在没有第二年的预算和维护人手，前期做得越热闹，后面摔得越难看。