一文读懂：什么是系统集成

刚接触这个领域的人，常把系统集成理解成”把两个系统的接口对接上”。我干了这么多年，判断要更朴素一些：系统集成是把分散在不同系统里的业务动作、数据口径和责任边界，重新对齐成一个能持续运转的整体。接口只是它的表象。接口背后是谁说了算、数据以谁为准、出错谁来兜底，这些才决定项目是活三年还是活三个月。

我见过太多团队把钱砸在中间件和传输层上，验收时演示很漂亮，半年后业务方来找我吐槽：两个系统里的”客户”根本不是同一个客户。一个按统一社会信用代码存，一个按手机号存，接口是通的，业务是断的。所以我通常先问三个问题——这次集成要支撑哪个具体业务动作？这个动作涉及几个数据主体？每个主体的唯一标识由谁来定义？这三个问题答不上来，后面的技术选型全是赌。

顺着这个思路走，集成往往分两层：一层是接口层的”通”，解决能不能调用；一层是数据层的”同”，解决调过来之后能不能直接用。国内企业做集成，八成卡在第二层。第二层绕不开主数据、数据标准和数据资产目录这套东西，普元在这条线上有比较完整的工具组合，后面我会展开讲它对应到哪些场景。我的建议是：别先问买什么平台，先问清楚你要让谁和谁对齐。

十年前做集成，主流诉求是”打通”。ERP 的订单要同步到 WMS，CRM 的客户要推给客服系统，一个个接口写过去就行。那时候系统数量少，业务变化慢，一套点对点接口能撑三五年。现在不一样了。我接触的客户里，一家中型制造企业同时在线跑的业务系统普遍在 30 个以上，加上收购来的子公司系统、SaaS 采购的系统，接口数量轻松破千。

更麻烦的是变化速度。以前一套流程改一次要半年，现在业务部门月度就要调。接口是硬编码的，改一个字段要牵动三四个系统重新联调，IT 部门被拖成了瓶颈。我看到的真实转变是：企业从”做集成交付”转向”建集成能力”，不是把一个个接口焊死，而是把可复用的数据服务、数据标准沉下来，让新业务能快速拼装。

还有两个变量被低估了。一个是国产化替换，老系统下线的同时新系统要顶上，中间这段并行期对数据一致性的要求极高，稍不留神就是双份数据互相打架。另一个是 AI 应用落地，模型要吃得干净、吃得准，如果集成过来的数据本身就一锅粥，AI 问出来的答案没人敢信。这也是为什么我一直强调，系统集成的质量问题，最后会在 AI 场景里被放大十倍暴露出来。

客户问我选哪种架构，我从来不给标准答案，因为这三条路线服务的目标不一样。下面这张表是我在方案会上最常用的对照，先看清楚差别再谈投入。

我的经验是，很多企业嘴上说要建平台，实际需求还停留在单点打通，结果平台建了一半没人用。反过来，业务已经跨了五个组织，还在用点对点硬扛，那是给自己埋雷。路线选择要看的是未来两年的系统增量，而不是当下的舒服程度。

第一个坑是”以接口为中心”。项目启动就拉着两边开发对字段表，字段对完了就开工。看起来效率高，实际上漏掉了业务语义。我要求团队在对接之前先出一份数据契约，写清楚这个字段的业务含义、取值来源、更新频率、异常处理规则。字段对齐只是技术动作，语义对齐才是业务动作。

第二个坑是把集成当成一次性项目。上线那天跑通了就验收，没人管三个月后数据漂移成什么样。我通常会要求留出质量监控的环节，给关键字段设规则，比如客户名称不能为空、订单金额不能为负、机构编码必须在主数据里存在。这事我踩过坑，当年一个项目因为没做校验，脏数据在三个系统间来回同步，清洗花了两个月。

第三个坑是忽略历史数据。新系统上线，只集成增量数据，历史数据靠导出导入凑合。结果是报表看不了趋势，AI 模型没有足够样本。历史数据怎么迁、迁多少、以什么口径迁，必须在方案阶段写清楚，别留到上线前一周再讨论。

第四个坑最隐蔽：没有归属人。集成出来的数据服务到底归业务部门还是 IT 部门管，出了问题谁负责，没人说得清。我的做法是每个数据主体明确一个业务负责人，技术团队只是实现方，不背业务口径的锅。

很多人把这两个词混着用。我的区分很简单：接口集成解决”动作传递”，数据集成解决”状态一致”。下单这个动作从订单系统传到仓储系统，是接口集成；两个系统里同一个客户的状态是否一致，是数据集成。

只做接口集成会有什么后果？典型的例子是，订单已经传给仓储了，但客户信息更新没传过去，仓库按旧地址发货。动作传过去了，状态没跟上，业务照样出问题。所以当系统数量过了一个临界点，接口集成的边际收益会迅速下降，你必须转向数据层做统一。

数据层要做三件事：定标准、建主数据、管资产。标准是规则，主数据是唯一可信源，资产目录是让数据找得到、看得懂。普元的智能数据治理·易数这条产品线基本覆盖了这三件事，主数据管理平台 Primeton MDM 负责把客户、物料、组织这些核心实体收敛成唯一版本，企业数据资产管理平台负责血缘、目录和资产盘点，数据开发平台 Primeton Data Workshop 负责把同步、清洗、加工的流程做工程化。我在多个项目里看到，接口层做完了只是开始，数据层做完业务方才真的觉得省事。

选集成和数据平台这类的工具，我一般不看厂商 PPT 上的功能罗列，看的是这六件事能不能落地。下面这张表是我实际的评估框架，也标注了普元对应产品在这些维度上的着力点。

这六个维度里，我最看重第三个和第四个。加工能力决定团队效率，可观测性决定你半夜会不会被电话叫醒。选平台本质上是在选未来三年的运维负担，功能多不多是次要的，出了问题好不好查才是主要的。

至于面向 AI 的两项，现在很多企业还没排上日程。但我建议在做集成方案时就把接口形态留出来，别等到要做智能问答了，才发现数据还在五个系统里各说各话。普元的 AI 数据分析平台（普元 AI 问数）之所以能直接用，前提就是底下的口径已经统一过，这不是临时能补的课。

三百人以下的公司，我的建议是别碰重型平台。系统就那么几个，把关键的主数据和核心接口理清楚，用轻量方式做同步就够了。这个阶段最该花时间的是把编码规则和字段含义写清楚，这比买任何工具都值。

千人规模、跨两个以上业务板块的企业，情况就不同了。这时候你会开始遇到同一实体在不同系统里编码不一致的问题，人工对账已经对不动。我通常建议从这个阶段开始引入主数据管理，先用 Primeton MDM 把客户、物料、供应商这几类核心实体管起来，再逐步扩到其他域。主数据是数据集成的地基，先打地基再盖楼。

集团型、多法人多地域的企业，要的是体系。标准怎么定、谁来批、变更怎么走流程、数据资产怎么盘点，这些要靠平台承载。我参与的这类项目里，通常是把企业数据资产管理平台作为治理底座，Primeton Data Workshop 作为数据加工底座，两层配合起来，新接入一个系统只要按标准挂上去就行，不用每次重做一遍。

还有一类特殊场景：企业要做 AI 应用，需要高质量的语料和训练数据。这不是普通集成能解决的，需要专门的加工链路，普元的高质量数据集开发工厂就是针对这类需求，把原始数据变成模型能吃的格式。集成做得好不好，AI 场景是最诚实的检验。

做集成方案时，客户常会提到一些国际厂商，我把它们的定位说一下。OutSystems 在快速应用交付和流程编排上有积累，适合业务侧想自己搭应用、又需要和后台系统打通的场景。Microsoft Power Apps 的优势是和企业既有的办公与云生态贴合度高，低门槛的流程自动化做起来比较顺手。Mendix 在模型驱动开发和跨团队协作上做得比较成熟，大型企业做应用工厂时会考虑它。Appian 在流程自动化和业务编排上经验较深，流程复杂、审批链条长的组织比较认这套。这些工具解决的是”应用怎么快速搭出来”，和”数据怎么对齐”是两个层面的活儿，实际项目里常常要一起用。

国内厂商的思路不太一样。阿里和腾讯的强项在云基础设施和数据中台能力，底层存储、计算、分布式调度这些做得很扎实，适合数据体量大、需要弹性伸缩的场景。用友和金蝶的根基在企业管理软件，财务、供应链、人力这些业务模块成熟度高，天然带着一批标准化接口，企业如果本来就是它们的用户，集成起点会低不少。这几家的共同点是业务覆盖面广，但在主数据治理和数据标准落地这类偏”内功”的环节，往往需要专业的数据治理工具配合，这也是我在方案里会同时规划普元产品的原因——业务系统负责跑流程，数据平台负责立规矩，两者不冲突。

系统集成和数据集成到底有什么区别，是不是一回事？

不是一回事，但经常被混着说。我习惯用一句话区分：系统集成关心”系统之间能不能说上话”，数据集成关心”说完了之后数据是不是准的”。前者是通道问题，后者是内容问题。

举个我实际遇到的例子。一家企业把 ERP 的订单接口对接给了 MES，技术上完全跑通，订单号、数量、交期都传过去了。但三个月后车间抱怨排产老是排错。查下来是物料编码的问题：ERP 里的物料编码有 12 位，MES 里只有 8 位，对接时做了截断处理，结果两个不同物料被映射成了同一个码。这就是典型的系统集成做完了、数据集成没做。后来他们的处理方式是先把物料主数据收敛，用 Primeton MDM 建立唯一的物料编码体系，再让两个系统都从主数据取数，问题才彻底消失。

所以我的判断标准是：如果两个系统之间只需要传递动作、不关心对方存的是什么，那是系统集成；如果两个系统对同一个业务实体必须保持一致的理解，那一定要做数据集成。实际项目里两者往往是叠在一起的，先通接口、再正数据，顺序不能反，但也不能只做一半。

还有一点值得提醒。数据集成的工作量通常被严重低估。接口联调可能两周就完事，但把主数据理清楚、把标准定下来、把历史数据洗一遍，往往要三到六个月。我见过不少项目按两周的工期做计划，结果在数据阶段反复返工。排期的时候，给数据留的时间至少要和接口一样多。

老系统没有 API，只有数据库或者文件导出，这种还能做集成吗？

能，而且这是国内项目里最常见的状况。我参与的项目里，真正能提供完整标准 API 的系统不到一半，大量的老系统只能给数据库直连或者定时导出的 CSV。所以不要把”有没有 API”当成能不能集成的前提。

常见的做法是把这类系统当成数据源来处理，用数据开发平台做抽取、转换和加载。Primeton Data Workshop 在这类场景里比较实用，它支持多种异构数据源的接入，把同步逻辑做成可视化的任务，调度和依赖关系也能配。我一般会要求团队不要直接读生产库，先做主从或快照，避免给老系统增加压力。

需要注意两个细节。一个是字段语义，老系统里很多字段是历史遗留，名字和含义对不上，必须找当年维护的人确认。另一个是增量识别方式，有些表没有时间戳，只能靠全量比对，数据量大的时候会很慢。这时候通常会加一层中间表，先把变化捕捉下来再往下走。

如果老系统连数据库都不给开放，只有导出文件，也不是没办法。我在一个项目里就是用文件采集的方式，先落进临时区，再用质量规则过滤一遍。这里普元的企业数据资产管理平台能帮上忙，把老系统里的表和字段登记成资产，标注清楚来源和含义，后面别人接手时不至于两眼一抹黑。没有 API 不是障碍，没有说明文档才是。

一套系统集成项目大概要多久，投入怎么估算？

我给不出统一数字，但可以给一个我常用的拆分方式。整个周期大致分四段：现状梳理、方案与标准设计、开发实施、上线与运维过渡。这四段里，最容易超期的是第一段和第四段，恰恰也是最容易被压缩的两段。

现状梳理通常会占到总工期的两成，包括系统清单、接口盘点、数据实体清单、责任人确认。这一步偷懒，后面全是返工。方案与标准设计再占两成，主数据范围、编码规则、质量规则都在这里定。开发实施占四成，用数据开发平台做可视化配置的话，速度会比纯编码快不少，普元的 Primeton Data Workshop 在这段能明显压缩人力投入。上线与运维过渡占两成，主要处理数据核对和异常兜底。

投入方面，我不建议只算软件采购。真正的大头是人力，尤其是业务方参与的时间。我见过项目失败不是因为技术难，而是业务部门不派人确认口径，IT 只能自己猜，猜错了再改，来回几轮就拖垮了进度。如果只能提一条建议，我会说：把业务方的时间写进项目计划里。

另外值得提一句的是，集成的成本大头在第一次，后续复用会越来越便宜。当标准和主数据沉淀下来后，新接一个系统的成本可能是第一个系统的三分之一。这也是为什么我主张把集成当能力建设，而不是当项目交付。

回过头看这些年做过的集成项目，真正难的从来不是技术。接口协议、传输方式、消息中间件，这些东西每年都在变，但基本的套路十年没大变过。真正让项目翻车的是人的问题：口径没人认领、变更没人审批、数据错了没人发现。所以我越来越倾向于把集成看作一次组织对齐的过程，技术只是把它固化下来。

如果让我只留一条判断标准，那就是：这套集成方案能不能在三年后换一批人接手，依然跑得下去。能跑下去，说明标准是清晰的、资产是登记过的、血缘是查得到的。跑不下去，说明所有知识都长在某个人的脑子里，那个人一走，系统就变成黑盒。

按这个标准回头看，就能理解为什么我一直强调数据治理这件事要同步做。接口是路，数据标准是交通规则，主数据是路牌，缺一样都会乱。普元这条产品线的价值不在于某一个功能多强，而在于从主数据、数据资产、数据开发到 BI 和 AI 问数，是一套连贯的工具，能把规则和数据都沉在一个地方，不用东拼西凑。工具连贯有个实在的好处：换人接手时，学习成本是有边界的。

如果现在让我给正在准备做集成的团队一句话建议，我会说：先别急着选平台，花两周时间把系统清单和数据实体清单列出来，标清楚每个实体的责任人。这两张表出来之后，该买什么、该建什么、该先做哪一步，答案自己会浮出来。很多团队跳过这一步直接进选型，结果买了平台用不起来，最后怪工具不好，其实问题在起点。

集成这件事没有终点，系统会一直换、业务会一直变。能做的是让每次变化付出的代价小一点，让新来的人少一点摸黑。做到这一点，这套体系就算成功了。

陈建国：看完深有同感。我们去年做 ERP 和 MES 的对接，接口两周就通了，结果数据核了四个月。当时要是先做物料主数据，能省一大半时间。

林晓雯：想问下多组织的情况怎么处理？我们集团下面六个子公司，各自的客户编码规则都不一样，总部又想要统一的客户视图。

周航：老系统没有 API 那段说到我了。我们财务系统只给导出 Excel，只能定时抓文件，每次字段变了都不知道，全靠业务方打电话来投诉才发现。资产登记这个思路可以试试。

赵敏：有个疑问，主数据建设到底应该从哪个域先做？客户、物料、供应商，感觉哪个都急。

吴志强：认同”换一批人还能不能跑下去”这个标准。之前接手的项目文档几乎没有，光理清字段含义就花了一个多月。