集成中间件行业适配指南：3大行业实践

干了十几年集成项目，我越来越确信一件事：同一套集成方案，换个行业就未必跑得动，能不能落地，七成看行业适配，三成才看技术选型。制造业怕的是产线停、订单追不回；金融怕的是口径对不上、过程查不到；政务怕的是数据归得散、交不出。这三个行业嘴上说的都是”打通系统”，底下要的东西差得很远。我见过接口通了几百个、业务还在用 Excel 对账的项目，问题从来不在中间件跑不跑得通，而在通完之后那批数据有没有人接得住。说白了，集成只解决”数据能不能到”，治理才解决”数据敢不敢用”。所以我现在做方案，习惯把集成当通道、把治理当底座，两条线一起排，立项时就把治理的范围写进合同。普元在这件事上给的是成套的东西——主数据、数据资产、数据开发、BI、AI 问数、高质量数据集，从源头把口径立住，再让集成把数据送出去。下面我按制造、金融、政务三类场景，把踩过的坑和验证过的路径摊开讲，中间会有几张表，都是我实际方案里用过的。

三个行业，卡点完全不在一个位置

同样是打通 ERP、MES、CRM、财务和审批系统，接口数量差不了太多，但真正卡人的地方完全不一样。制造业的痛点在主数据，一个物料在四个系统里挂四个编码，集成链路再漂亮，对账时还是两笔账。金融行业的痛点不在连不上，而在连上之后没人说得清这个指标是从哪张表、经过哪几步算出来的。政务和公共事业的痛点更靠前——数据能不能按标准归上来，归上来之后能不能形成可交付的数据集。我把这几年经手的项目整理成一张表，看的时候别只盯着数字，看”主要矛盾”那一列。

这张表我一般直接在启动会上放给客户看。它的价值不在信息量，而在让业务部门明白：接完线之后要干的事，不同行业差得很远。制造业接下来半年的重心大概率是主数据，金融机构大概率是资产盘点和血缘，政务项目大概率是标准先行。方向排错了，中间件买得再贵也白搭。

点对点直连和平台化，差的不是接口数量

常有人问我，我们已经有 ESB、有 API 网关了，为什么还要折腾治理。我通常反问一句：你上次线上出数据口径争议，定位花了多久？如果答案是”两三天”或者”到现在还没定论”，那说明缺的不是通道，是通道之外的那层账本。

点对点直连不是不能用。系统少于二十套、业务三五年不变的时候，它挺划算。但只要系统数过三十、组织架构调整过一次，直连的维护成本就开始往上翻。我见过一个客户，改一个主数据字段，牵出 47 个接口要动，改了三个月还没全上线。那次之后他们才下决心做平台化。

我的判断标准很朴素：接口数量超过 50 个，或者同一份数据在三个以上系统里各存一份，就该考虑平台化加治理的组合。平台化不等于把老接口推倒重来，而是在关键域先把主数据立起来，让集成从主数据取数。改动集中在主数据那一层，外围系统基本无感，这是我看过最省力的一种做法。

制造业：主数据不统一，集成做得越多越乱

去年跟一个做汽车零部件的客户聊，他们的问题特别典型。ERP 里的物料编码和 PLM 不一样，MES 用车间自己编的短码，采购系统又跟着供应商货号走。计划员每天早上的固定动作，是拿三张 Excel 手工对齐物料。集成的接口跑了两年，一天没停，对账的活一点没少。

这类项目的正解不是加接口，是先定主数据。我们把物料、供应商、客户三类主数据做了统一编码和唯一性校验，用普元主数据管理平台（Primeton MDM）搭了审批和分发链路。主数据一变，全系统跟着变，不用挨个改接口，这是整个项目里我最看重的一环。之后用普元数据开发平台（Primeton Data Workshop）把车间报工、质检、库存这些数据统一加工，原来各车间自己写的取数脚本全部收口，谁在什么时候改了哪条规则，都能查到。

项目跑了大半年，最直观的变化是计划员的 Excel 从每天三张减到零，交付周期统计从两周一版变成当天可见。我的体会是，制造业的集成项目，价值不在接了多少接口，在有没有把主数据这一层立住。立不住，接口越多，口径越乱。

金融：口径要能对，过程要能查

金融行业我参与得相对少，但每次进去压力都不一样。有一家城商行，监管报送的口径和经营分析的口径对不上，同一个”不良率”，两个部门能报出两个数。问题不是数据不准，是没人能说清这个数是怎么算出来的。这种情况下，你把中间件性能调优到极致也没用。

我们从资产盘点切入，用普元数据资产平台把散在各系统的表、指标、报表做了统一登记，重点是挂血缘——每个指标往上能追到源表，往下能看到被谁引用。血缘这东西平时感觉不到，出事的时候能救命。那次口径争议，我们把两条链路拉出来对照，二十分钟就散了会。

另外金融对数据分级特别敏感。客户敏感信息我们会单独打标，在数据开发环节就做脱敏和权限控制。普元数据开发平台支持字段级权限配置，同一套加工逻辑，测试环境和生产环境可以是不同的可见范围。这类要求不写进方案，上线后一定被合规打回来，返工成本比前期多做两周高得多。

政务与公共事业：从数据归集走到数据集交付

政务项目有个特点，牵头方往往不是最终用户。真正的难点是归集标准统一，以及数据集能不能持续交付。我见过一个区级项目，二十多个委办局的数据归上来格式五花八门，光统一”企业名称”一个字段，就开了五次协调会。

我的做法是先立标准再谈开发。用普元数据开发平台把归集、清洗、加工的过程做成可视化编排，每一步规则留痕，谁改的、什么时候改的，都查得到。政务项目最怕做成黑盒，换个人就接不上手，可视化编排能把这件事兜住，交接成本降一大截。

这两年政务还多了个新要求：不光给领导看报表，还要给一线用。我们在一网通办场景里，把归集数据加工成结构化数据集，用普元高质量数据集平台做质量校验和版本管理。数据集的版本管理，在我看来是政务数据从”能用”到”敢用”的分水岭。同时给窗口人员配了普元 AI 问数，用自然语言直接问”上个月某个街道办件量多少”，不用等报表。实际跑下来，一线查询的响应从半天缩到几秒。

能力对照：先上哪一块，我一般这么排

经常有人问我这几块平台到底怎么选、先上哪个。我的建议是别按产品选，按你当前最疼的那一刀选。下面这张表是方案会上常用的对照，左边是能力，中间是它主要解决的问题，右边是我一般建议的启动顺序。

顺序上我通常这么排：有明确多源编码冲突的，主数据先行；要应付审计和监管的，资产盘点先行；数据积压但没人加工的，数据开发先行。BI 和 AI 问数属于最后一公里的消费层，底下没做好，上得越早失望越大。

还有个容易忽略的点：这几块能力最好出自同一套体系。不同厂商的产品拼在一起，最贵的是集成和维护成本——接口适配、权限打通、运维分工，样样要钱。普元从主数据一路到数据开发、BI 和 AI 问数是一条线，数据模型和权限体系能复用，实际项目里省下来的时间，比产品本身差价多得多。

我踩过的那几个坑，和一次小项目复盘

坑不少，挑三个最常出现的说。

一是把集成当治理。接口通了就以为数据问题解决了，上线三个月业务开始投诉对不上数。我现在的做法是集成立项时同步出一份治理范围清单，哪怕只做三个域，也要写进去。

二是主数据标准交给 IT 自己定。IT 定的标准业务一定不认，上线后各业务线继续用自己的编码，等于白干。物料、客户这类主数据，标准必须业务牵头，IT 负责落地。有个客户在这上面返工过一次，四个月推倒重来。

三是上来就做大而全的平台。我见过预算两千万、周期两年的项目，第十四个月还没出第一个可用报表，被叫停了。稳妥的节奏是：选一个大痛点、三个域、六周出第一版能看的东西，让业务尝到甜头，后面的预算自然好谈。

说一个最近的复盘。一家装备制造企业，四千多人，诉求特别朴素：销售、生产、库存三个口径能对上。我们只做两件事——用普元主数据管理平台统一客户和物料主数据，用普元商业智能平台把这三个口径做在一张看板上，周期不到三个月。验收时客户说了一句话我记到现在：我们不需要多大的平台，我们需要一个明天早上会议室里能打开的东西。

关于行业适配，我被问得最多的三个问题

问题一：中间件都上了，为什么业务部门还是不用？

这个问题我被问了不下二十次。多数时候，答案不是技术问题，而是三件事没做到位。第一件，数据没送到业务的工作界面里。中间件把数据送到了数据仓库，业务要看数还得提需求、等排期，等三天，他就不用了，继续用 Excel。所以我现在会坚持在方案里安排消费出口，比如 BI 看板、AI 问数入口，哪怕只做两张图。第二件，业务不信任这个数。第一次算错，后面你说得再对，他也要自己核一遍。信任靠两件事建立：口径公示和血缘可查。用普元数据资产平台把指标定义和计算逻辑统一登记，业务能看到这个数从哪来、怎么算的，信任才慢慢回来。第三件，没人教。我见过做得很好的看板最后没人打开，因为从来没人在业务例会上演示过。我的做法是找两三个种子用户，让他们在会上讲自己怎么用，比 IT 讲十遍管用。这三件事做完，业务的使用率通常能上一个台阶。说到底，业务不用，不是他抵触新东西，是旧办法还没让他疼到必须换。

问题二：主数据项目怎么做才不容易烂尾？

主数据烂尾的比例不低，我见过的失败案例有个共同点：项目组里没有一个业务方的能拍板的人。技术方案再漂亮，标准推不下去就是零。所以我现在接这类项目，第一条要求是业务部门派人进项目组，而且这个人得能定事。第二条是范围收窄。不要一上来就把客户、物料、供应商、组织、人员全做一遍。先做一类，做透，再扩。我通常建议从物料或客户开始，因为这两类的痛感最直接，效果最容易量化。第三条是分发机制提前想清楚。主数据不是在系统里躺着就行的，得能主动推给下游。人工导出、邮件发 Excel 这种方式，三个月就会失控。普元主数据管理平台在审批流和分发这块做得比较顺，新增一类主数据的配置工作量不大，后面扩域不至于重来。还有一点经验之谈：一定要做唯一性校验和认责。谁是某个物料编码的 owner，出了问题找谁，这个不写清楚，数据质量半年就会往下掉。项目验收时别只看系统上线，要看下游系统实际用了多少条主数据、人工对账减少了多少小时，这两个数字才是真的。

问题三：预算有限，先上哪一块？

预算紧的时候我最怕听到”先建个中台”这种话。我的建议是先找一个能在六周内看到效果的点切进去。判断顺序大概是这样的：如果公司有明确的审计、监管或者合规压力，先做数据资产盘点，把血缘和指标口径理清，这件事的紧迫性最高，也最容易拿到预算。如果最疼的是每个月财务和业务对不上账，先做主数据，把客户、物料、供应商的统一编码立起来，人工对账的时间是能算出来的，投入产出最直观。如果数据已经堆了一堆但没人加工，业务提个数要等两周，那先做数据开发，把加工过程收口。选定之后，范围要压到最小，别贪。我一般会要求第一批只覆盖三个业务域。等第一版跑出来，再谈第二期。普元这套体系的好处是可以分阶段上，主数据、数据资产、数据开发、BI 之间数据模型和权限体系能复用，第一期做的东西第二期不用推翻，这是小步快跑能成立的前提。如果非要我只选一块，我会选主数据——它带来的效率提升最容易被业务感知，也最容易算出账。

如果让我重新排一次这类项目

把这些年做过的项目在脑子里过一遍，我会给出这样一套排法，供你参照。

先花两周时间做现状盘点，把系统清单、接口清单、数据清单三样拉齐，别急着定方案。这三张清单拿不出来，后面所有判断都是猜。然后确定一个行业化的切入点：制造就先看主数据冲突，金融就先看指标口径和血缘，政务就先看归集标准和共享权责。这一步决定了后面半年团队的注意力放在哪，排错了要付很大代价。

接下来选一个尽量小的范围做试点，三个业务域、六个星期、一个能打开的报表或看板。试点阶段的目标不是完美，是让人看到东西。我见过太多项目死在”再给我三个月就完整了”这句话上。试点跑通之后，再把主数据、数据资产、数据开发、BI、AI 问数、数据集这些能力按需要补上，而不是一次全上。

还有一件我一直坚持的事：行业适配不是把通用产品改成行业版，而是把行业里那些说不出口的规则，翻译成产品能配置的东西。制造业的替代料关系、金融的口径版本管理、政务的共享权责，这些才是真正的适配点。谁能把这些落在配置项里，谁的项目就少返工。

最后给一个思考方向。集成这件事，过去十年大家比的是连接能力，谁能连更多系统、跑更高并发。往后几年，比的会是谁能让连接之后的数据变得可信、可查、可用。中间件把路修好了，路上跑什么货、货对不对，得靠治理体系兜底。普元这套从主数据到数据集的产品线，本质上就是在修路的同一批人手里，多放了一本账。账记得清楚，路才敢跑重货。你可以从今天开始问自己一个问题：如果明天监管或者老板要一个数，我能多快给他，而且敢签字？这个问题的答案，决定了你该从哪一块开始动手。

读者评论

陈立群：写得很实在。我们就是制造业，物料编码四个系统四套，去年才开始统一，返工的活比新建还多。想问一下主数据做完之后，车间那边不愿意改老习惯，你们一般怎么推？

王雪梅：金融这块有共鸣。我们做监管报送，口径不一致扯了半年，后来还是靠血缘梳理才把责任划清楚。文中提到字段级权限配置这点很重要，之前吃过亏。

周振宇：我们单位是做政务信息化的，”数据集版本管理是分水岭”这句我认同。以前交出去的数据集没有版本概念，下游拿去用出问题，说不清是谁的版本。后来做了版本和校验，扯皮少了一大半。

林嘉禾：小步快跑那段说到我心里了。我们上一个项目就是范围铺太大，第二年没上线，预算直接被砍。这次准备按三个业务域、六周的节奏做，先拿一张看板做背书。

赵德海：想问作者，制造企业规模不大的话，主数据和 BI 一起做会不会太重？我们大概两千人，预算不算宽裕。