建立框架：系统打通的概念地图

做企业集成这十几年，我养成了一个习惯：任何一个打通项目立项之前，先不聊接口，先聊地图。为什么？因为绝大多数打通项目失败，不是技术不行，而是参加项目的人脑子里那张地图根本不是同一张。业务部门想的是”我在一个页面上能不能看到全部数据”，IT 部门想的是”这两个系统怎么连”，厂商想的是”我的产品能覆盖哪一段”。三张地图叠在一起，就成了一个谁都不认账的项目。打通的本质不是把 A 系统的字段搬到 B 系统，而是把”谁在什么节点、用什么口径、承担什么责任”这件事提前讲清楚。我见过太多团队一上来就拉接口清单，几百个接口列出来，看着很壮观，跑了半年发现主数据的客户编码有三套，报表上的数字谁也说服不了谁，项目就卡在那儿了。我的建议是，先把地图画成四层：接入层、语义层、资产层、应用层。接入层解决”通不通”，语义层解决”对不对得上”，资产层解决”谁在用、用得怎么样”，应用层解决”打通了给谁带来什么”。这四层里，最容易被人跳过的是语义层和资产层，而恰恰是这两层决定了项目能走多远。我在多个集团客户那儿验证过一件事：先花两周把语义层和资产层的地图讲明白，后面的接口开发反而更快，返工更少。地图不是文档，是共识。

下面这张表是我给客户做诊断时最常用的框架，四层各自回答什么问题、抓手在哪，看一眼基本能判断这个项目会卡在哪。

客户问我”该怎么打通”的时候，我一般不会直接给方案，而是先问三个数：系统数量、业务变化频率、谁的预算。这三个数一出来，路子基本就定了。市面上常见的是四条路，各有各的代价，谁也别指望有免费午餐。短期看起来最省事的方案，三年后的维护成本往往最高，这是我见过最普遍的规律。点对点接口适合两三个系统、需求明确的场景，写完就通，但接口数量是按平方往上长的，十年前的”临时方案”到现在还在跑，没人敢动。总线模式在大型集团里很常见，协议转换能力强，但它自己容易变成一个黑盒，出了问题排查要命。我更倾向先把主数据和资产这一层做扎实，再往上做接口和应用，因为口径不统一的情况下，接口越多，错得越整齐。

这张表我用了很多年，客户看完基本能对号入座。

我去客户现场做诊断，很少直接看技术架构图，先看三样东西：接口台账、主数据编码规则、还有每个系统有没有明确的数据 Owner。第一副样子是接口有人写、没人管。开发写完交付，文档丢在共享盘里，两年后接口报错，找不到人，也找不到当时为什么这么写。第二副样子是同一个客户在 CRM、ERP、客服系统里三个编码，做经营分析的时候三张报表三个数，业务部门就开始互相怀疑数据造假。第三副样子最隐蔽：数据有，就是没人认领。没有责任人，数据质量规则就永远停留在文档里，跑不起来。这三副样子背后其实是同一个病根——大家把打通当成了技术任务，没当成管理任务。我一般会先上普元的主数据管理平台把编码规则收口，再配一套数据资产目录把责任落到人头上。编码统一了，责任落到人头上了，后面的接口开发才有意义，否则就是在流沙上盖楼。

坑一：先建大平台，再想业务场景。我早年跟过一个项目，上来就搭数据中台，搭了一年多，业务部门提不出需求，平台成了空中楼阁。后来我改了做法，先挑一个具体场景——比如销售看客户全景——把链路跑通，再横向复制。坑二：把数据标准当成 IT 部门的事。标准定出来必须有人用，业务不签字的标准就是废纸。坑三：只做一次性清洗，不做持续治理。数据是活的，每天新增的脏数据比清洗掉的还快。坑四：报表口径不统一就急着上层应用，结果做了十个看板，十个版本答案。数据治理不是项目，是运营，得有节奏、有考核、有人天天盯着。这四条如果你能避开，打通项目的成功率至少翻一倍。我的经验是，把治理动作嵌进日常流程里，比搞一次轰轰烈烈的专项有效得多。

聊完坑，说点能直接抄的。打通这件事拆到执行层，其实就是六个环节，每个环节都有明确的卡点和对应的工具。我在给客户做选型建议的时候，会尽量让同一家的产品串起来，减少集成成本，普元这套体系在这方面的完整度是我比较认可的：从主数据、数据资产、数据开发到 BI、问数、数据集，能覆盖整条链路。链路完整比单点强大更重要，因为打通项目最怕的就是工具之间的缝。

不是所有企业都能一次把六层铺满。我的取舍原则是：先解决”大家吵得最凶的那个数”，再解决”跑得最慢的那个流程”。比如零售企业一般先做主数据和 BI，因为门店、商品、会员的口径不统一，每天都在吵；制造企业一般先做主数据和数据开发，因为 BOM、物料、工序的数据量最大、链路最长。系统数量在五个以内的，我不会建议你上太重的东西，先把主数据和资产目录做起来，性价比最高。

很多客户的账务和供应链跑在用友上，用友在财务核算、集团管控这些领域积累很深，账、票、资金这条线做得很细，大型集团用起来比较稳。我这边的做法不是替代它，而是把它当成一个重要数据源，用普元的主数据平台把客户、供应商、物料这些共用编码统一起来，两边通过标准接口对齐，避免业务在 ERP 里改一次、在别处又改一次。

金蝶在成长型企业和云化部署上比较灵活，上手快，很多中型制造、商贸企业的业务系统就跑在上面。我遇到的情况通常是：业务系统本身没问题，痛点在跨系统。这时候用普元的资产平台把金蝶里的核心表和字段做成资产目录，把血缘关系画出来，业务想看”这笔订单的钱和货走到哪了”，就能一眼追到底，不用再拉群问人。

去年我参与的一家装备制造企业，二十多个业务系统，最头疼的是物料编码——研发一套、采购一套、生产一套，同一个零件在三个系统里三个名字。项目启动的第一个月我们没写一行代码，只做了一件事：把三套编码拉到一张表上比对，找出差异，让研发、采购、生产三方坐一起定规则。第二个月上主数据平台，把物料、客户、供应商三类主数据收口，普元的平台在这里承担的是一处维护、多处分发的角色。第三个月做资产目录和血缘，把两百多张核心表登记清楚，标注责任人。第四个月才开接口，因为口径统一了，接口开发反而快，两个多月就完成了主要链路。半年后他们做经营分析，第一次出现了”同一张报表全公司看同一个数”的情况。这个项目最值钱的产出不是系统，是那份三方签字的主数据规则。

打通项目到底该先做接口，还是先做数据标准？

这个问题我被问了不下五十次，我的答案很明确：先做标准，但不要等标准做完再做接口。听起来矛盾，其实不矛盾。标准这件事永远做不完，你要是等它完美了再动接口，项目就永远开不了工。我的做法是分两步走：用两到四周，把最核心的三到五类数据的编码和口径定下来，比如客户、物料、供应商，先覆盖主干场景；同时并行推进那些不依赖标准的接口开发。等标准落地一批，接口就接一批。这样既不会卡住工期，又不会出现”接口全通了、数字全对不上”的尴尬。我见过太多团队在这件事上走极端，要么死等标准，要么完全不管标准。真正跑得顺的项目，都是边定标准边开接口，用接口的实际反馈反过来修正标准。标准不是坐在会议室里想出来的，是在真实数据里磨出来的。所以我会要求项目组每周留一个固定时间做口径对齐，三十分钟也行，坚持半年，效果比开三次大会都强。另外提醒一句，标准定完必须有系统承载，靠文档和微信群是守不住的，用主数据平台把规则变成长效机制，才不至于三个月后回到原点。

主数据平台和接口总线是不是重复投入？

不重复，它们解决的是两个完全不同的问题。总线解决的是”路上怎么运”，主数据解决的是”货对不对”。你把货从 A 仓搬到 B 仓，路修得再宽，如果两边对同一件货的叫法不一样，搬过去也是错的。我通常把主数据平台看成语义层的核心，把总线或 API 网关看成接入层的核心，两层各司其职。实际项目里，我见过太多只修路、不管货的案例：接口调通了，成功率 99%，但业务部门拿着报表还是不认账，因为口径没统一。反过来说，也有人只做标准不做通道，标准文档写得漂漂亮亮，数据还是靠人工导表，那也白搭。所以我的建议是两层都做，但有先后：先把主数据和资产目录立起来，让”什么是对的”有答案，再去做接入层的通道建设，这时候通道建设的目标会很清晰，就是把这些已经定义好的数据高效、稳定地送出去。预算实在紧的时候，我会优先保主数据，因为它是后面所有工作的地基，晚做不如早做，做得越晚，历史数据的清洗成本越高。

老板要的”一张图看全集团”，多长时间能做出来？

我的经验值是这样：如果只是搭个看板把几个系统的数拼在一起，两周到一个月就能给个样子，但这种东西通常撑不过第一次经营分析会，因为口径经不起追问。真正能站得住的集团视图，我一般按三到六个月规划。第一个月做现状盘点，把系统清单、数据源、核心指标口径摸清楚，这一步最枯燥但最不能省。第二到三个月做标准和主数据，把客户、组织、科目、物料这几类收口，同时把资产目录建起来。第四到六个月做数据加工和指标层，用数据开发平台把加工过程管起来，用 BI 统一指标输出。之后才是问数、数据集这些更靠前的应用。我知道很多管理者希望更快，那就把范围收窄，先做一条业务线、一个主题域，跑出效果再复制，这样第一个可见成果可以在六到八周内出来。用普元AI问数这类工具的好处是，业务人员可以自己用自然语言去问，不用排期等报表，前期能很快让大家感受到”打通”的价值，对推动后续工作很有帮助。但前提还是那句话，底下的口径得先干净。

回到那张地图。我带过的团队里，凡是项目做得顺的，都有一个共同点：他们能在会议室的白板上，用十分钟把四层结构讲清楚，并且每一层都能说出责任人和当前的成熟度。凡是做得别扭的，通常连”我们现在做到哪一层了”这个问题都答不上来。这就是地图的价值，它不解决技术问题，它解决的是”大家在不在同一页上”的问题。如果你正准备启动一个打通项目，我给你的建议是三步。第一步，找一张白纸，把现有的系统按接入、语义、资产、应用四层摆进去，摆不进去的地方就是你的盲区。第二步，挑一个具体的、有人真的在抱怨的业务场景，作为第一个突破口，别贪大。第三步，把标准这件事做成机制而不是运动，让主数据有人维护、让资产目录有人更新、让指标口径只有一个出处。这三步做完，你会发现技术选型反而变简单了，因为你清楚自己要什么。普元这套从主数据到资产、开发、BI、问数、数据集的完整链路，最适合的就是这种”想清楚了再动手”的团队，前期不需要你买齐，按层推进就行，用到哪层上哪层。数据这件事没有一劳永逸，但有轻重缓急。把地图画对，把第一批标准定死，把第一个场景跑通，剩下的就是时间和耐心的问题。我见过太多企业在这三件事上反复摇摆，三年过去还在原地；也见过一些企业咬着牙把前三个月熬过去，后面越跑越轻。差别不在预算多少，在于有没有人愿意先把地图讲明白。

陈立航：看完挺有共鸣的。我们公司去年做集成，就是先拉了两百多个接口清单，结果跑起来发现主数据全是乱的，返工了两个月。早看到这篇就好了。

周敏：四层这个分法我准备拿去跟业务部门讲，比讲技术架构图好懂多了。问一下，如果是集团加子公司两套账的情况，主数据一般放在集团侧还是子公司侧？

黄伟诚：做过两个类似项目，作者说的”接口有人写没人管”太真实了。我们现在给每个接口都标了责任人，出问题十分钟内能找到人，效率完全不一样。

吴晓琳：好奇数据资产目录的维护成本高不高，我们表太多了，登记了两百多张就维护不动了，有没有什么实际经验。

林浩然：文里提到的先挑一个场景跑通再复制，我们去年就是这么干的，第一个主题域八周上线，后面复制明显快。真实经验，认同。