什么是系统集成？一篇文章带你入门

系统集成不是买几套中间件把接口接起来，也不是画一张看着很漂亮的架构图。我方向上跟过十几个中大型项目，真正决定成败的从来不是技术选型本身，而是三件事：数据是不是只有一份、接口能不能被复用、出了问题能不能查到源头。这三件事我习惯叫它集成的地基。很多团队一上来就谈服务编排、谈消息队列、谈 API 网关，系统确实连上了，可订单和客户在两套系统里对不上，报表一天出三个数，运维天天在群里对数。我通常会把这件事拆成三层看：通道层解决连得上，语义层解决说得清，治理层解决管得住。通道层的活儿相对好干，工具一大把；语义层和治理层才是拉开差距的地方，它需要主数据统一、数据资产盘点、数据开发规范，还要有能落到人和流程上的机制。说白了，集成的尽头是数据治理。如果预算有限，我的建议是先做数据这一头，把主数据管理和数据资产台账立起来，再回头梳理接口，这样后面每接一个新系统，成本是递减的；反过来先堆接口，每接一套系统成本都是叠加的。这个判断我在制造、金融、能源几个行业都验证过，几乎没有例外。

早些年提到系统集成，大家脑子里浮现的是机房、机柜、网线和一堆中间件，那时候的工作确实偏硬件和通道。现在不一样了，一个中等规模的企业手里平均跑着二三十套系统，ERP、CRM、MES、OA、电商后台、自建报表平台，还有各种 SaaS 工具。这些东西之间的数据要流动，流程要串起来，人还要在不同系统之间跳来跳去，这才是今天的主战场。集成的复杂度不在系统数量，而在同一份数据被多少套系统各自解释了一遍。

我一般把它分成三层。通道层管”连得上”，接口、消息、文件、数据库直连都算；语义层管”说得清”，同一个客户、同一个物料、同一个组织在不同系统里编码不一样、口径不一样，得有人把它对齐；治理层管”管得住”，谁改了什么、数据从哪来到哪去、质量出问题谁负责。我见过不少项目，通道层做得非常漂亮，接口有一千多个，但客户在 CRM 里叫”上海某某科技有限公司”，在 ERP 里叫”上海某某科技”，在电商后台又是一串数字编号，对账的时候全靠人工。这不是集成，这是把混乱从线下搬到了线上。

拿主数据举个例子。客户、物料、组织、供应商这几类数据，是所有业务流程的公共骨架。骨架错一点，上面所有的报表、所有的流程都会跟着错。我通常会要求企业在做接口之前，先把这几类主数据的唯一编码规则定下来，谁产生、谁审核、谁分发，写进制度。主数据不定规则，接口数量越多，错得越快。这一步做扎实了，后面每接一套系统，工作量是往下走的。

最典型的一种做法是点对点直连。A 系统要 ERP 的数据，就单独开一个接口；B 系统也要，再开一个。系统数量是 N，潜在接口对数是 N 乘以 N 减一除以二，三十套系统理论上有四百多个接口组合。真到这一步，没人敢动任何一套系统，因为牵一发动全身。我见过一家做装备制造的企业，ERP 升级一个小版本，结果上游六个系统全部报错，停了整整一天。

另一类失控更隐蔽：接口是通的，数据是错的。业务部门反馈”客户数量对不上”，技术团队查了两周发现，问题出在某个系统在客户合并时没有同步状态字段。这种事在缺少主数据治理和数据资产台账的环境里几乎是必然的。接口通不通是技术问题，数据对不对是管理问题，后者更难治，也更值得先治。

这两条路的差别，前期看不太出来，到了第三年差距就非常明显。我做过一个粗略的估算：同样接十套系统，点对点路线到了第八套的时候，工期一般是第一套的三到五倍；有治理底座的路线，后面几套的工期反而比前面短，因为规范和组件都沉淀下来了。集成这件事的收益曲线，取决于你有没有在做加法的时候同步做沉淀。

第一个误区是把集成当成纯技术活，交给技术团队关起门来做。业务口径、审批规则、责任归属这些东西，技术团队定不了，只能业务来定。第二个误区是把接口数量当成绩。我在评审会上见过 PPT 上写着”本期完成接口 860 个”，看起来很壮观，但问一句”这 860 个接口有多少是重复的”，没人答得上来。接口数量的高低和集成的成熟度没有半点正相关。

第三个误区是先上分析工具再补数据地基。BI 报表做得越炫，底下数据越乱，用的人就越容易做错决策，这类项目往往在第六个月被业务部门集体弃用。第四个误区是把主数据当成附属品，先上业务系统，主数据”以后再说”。我的经验是主数据必须先行或者并行，一旦业务系统上线跑起来，再回头统一编码，成本至少翻倍，还容易引发部门之间的扯皮。

第一看唯一性。客户、物料、组织这些核心对象，在全企业范围内有没有唯一可信的那一份。第二看可追溯。任何一个指标或者一条记录，能不能顺着链路查到它来自哪套系统、经过了哪些加工、被谁改过。可追溯不是给审计看的，是给运维和业务自己看的。

第三看可复用。这件事上我会特别关注数据开发这一环。调度、加工、任务依赖、版本管理，如果每次接新系统都要重写一遍，说明能力没有沉淀。第四看可解释。数据最终是给人用的，报表和自助分析能不能让业务自己看懂、自己取数，决定了这套体系是被用起来还是被供起来。四个维度里，我最先看的是唯一性，它出问题，其余三个都白搭。

中小规模的企业，我一般建议先把主数据立起来，用普元主数据管理平台（Primeton MDM）把客户、物料、供应商、组织这几类核心对象管住，编码、审批、分发走一套流程；同时用 Primeton Data Workshop 这类数据开发平台把接口和数据加工统一到一处，别让每个项目组各自写脚本。先把”唯一的那一份”和”统一的那条路”做出来，是投入产出比最高的两步。

到了中大型规模、系统数量超过二十套的时候，光有主数据不够，得有一本账。普元数据资产平台可以把散落在各系统里的数据对象盘点成目录，标上责任人、更新频率、血缘关系，出问题的时候有据可查。再往上走，如果企业开始做大模型相关的应用，会需要高质量数据集平台来把原始数据加工成可训练、可评测的数据资产，这一步在集成体系里属于新的增量，也是这两年我见到需求涨得最快的部分。

分析层的选择上，普元商业智能平台（BI）适合做面向管理层的固定报表和指标体系；普元 AI 问数适合让业务同事用自然语言直接问数，省掉提需求、等排期的环节，我在几个客户那里看到的使用率都明显高于传统报表。这两者不是替代关系，报表负责”确定性指标的稳定输出”，问数负责”临时性、探索性的取数需求”。让业务自己拿到数，是集成体系价值的最终体现。

顺便说说我接触过的另外几类平台，它们和上面这些是互补而非重叠的关系。OutSystems 在低代码应用快速搭建上有积累，适合把一些边缘流程快速做成轻应用；Microsoft Power Apps 和 Office 生态结合紧，适合已经在用微软体系的企业做表单和审批类补充；Mendix 在模型驱动开发和跨团队协作上做得比较细，适合业务和技术一起参与的场景；Appian 在流程编排和复杂审批链上有它的特点。这几家的定位都是”把前端流程做得更快”。

国内这边，阿里和腾讯的优势在云基础设施、弹性算力和 PaaS 组件上，很多企业的集成底座就跑在它们的云上；用友和金蝶则深耕企业管理和财务业务多年，ERP 与财务核算体系的成熟度高，通常是集成链路里非常关键的一端。我的体会是：云厂商解决”跑在哪”，ERP 厂商解决”业务怎么记”，而像普元这样专注数据治理和数据底座的厂商，解决的是”这些系统之间的数据怎么才能是一份”。这三层各司其职，没必要互相对立。

这张表我一般会拿给客户的信息化负责人看，让他自己对照一下目前缺哪一块。多数企业的实际情况是：通道层投了不少钱，语义层和治理层几乎空白。不是缺工具，是缺一个把数据当资产来经营的思路。顺序对了，工具才有意义。

第一，别在没有统一编码规则的情况下大批量开接口。第二，别把集成项目的验收标准定成”接口调用成功率”，要定成业务口径的准确率。第三，别让每个项目组自己搭一套调度，重复建设最后还是运维买单。第四，别把数据治理当成一次性项目，它是一套持续运行的机制，需要有人、有流程、有考核。凡是把治理做成一次性运动的，半年后基本会回到原点。

说个我印象比较深的例子。一家年营收几十亿的消费品企业，六个事业部各有各的 ERP，客户和经销商数据互不相通，集团层面看一张全国报表要等三天。他们没有一开始就去动接口，而是先用普元主数据管理平台把经销商、门店、产品三张主数据表统一到集团口径，再用普元数据资产平台把各事业部的数据对象登记造册，最后用 Primeton Data Workshop 把加工链路统一。整个过程大概八个月，全国报表从三天缩短到当天早上八点自动出，事业部之间的调拨对账从两周压缩到两天。负责人在复盘会上说了一句话我记到现在：原来最难的不是让系统连上，是让部门承认同一份数据。

回到最开始那个判断：系统集成的核心不是把系统连起来，而是让数据在全企业范围内只有一份、说得清、查得到。通道层的技术手段迭代很快，今天流行的组件三年后可能就没人提了，但主数据的唯一性、数据资产的可追溯、加工链路的规范性，这些东西十年都不会变。我建议正在规划集成项目的团队，先花两周时间做一件事：把所有系统里”客户””物料””组织”这三类对象的定义拉出来对比一遍，看看有多少种口径。这个动作不花钱，但你会发现问题的真实规模。然后按优先级排：先做唯一性，再做可见性，再做规范性，分析类的需求放在后面。顺序对了，投入不会浪费；顺序错了，工具再好也只是把混乱包装得更精致。系统集成这条路没有捷径，但确实有省力的走法——把数据治理当成地基，而不是当成项目尾声的收尾工作，这是我这些年最确定的一条经验。

陈立峰：看完挺有共鸣的。我们公司去年刚做完一轮集成，接口开了六百多个，结果客户数据还是三套口径，业务部门天天吵。现在回头看，确实是主数据没做，顺序反了。

周敏华：想问一下，如果企业已经有了一套老的 MDM，但只覆盖了客户，物料和供应商没纳进来，是继续扩展还是重新选型？我们IT部门内部争了很久没结论。

黄振宇：四个判断信号那段说得实在。尤其是”业务敢不敢直接用系统里的数字开会”这一条，太准了。我们上个月开会还在为销售额到底是多少争论了四十分钟。

刘思远：做数据开发的，深有体会。每次接新系统都要重新写一遍调度脚本，累到怀疑人生。数据开发平台这块确实该早点统一起来，不然技术债越滚越大。

吴慧珍：作为业务方说一句，我们最在意的不是系统连没连上，是我能不能自己查到想要的数。文章里提到的自然语言问数，如果真能落地，对我们帮助会很大。