从案例看系统集成价值：完整解析

做了十几年企业信息化，我很少见到哪个项目是因为接口写得漂亮被业务记住的。真正被业务记住的，往往是某次对账对不平、某张报表两个系统数字打架、某个客户在 CRM 和 ERP 里挂着两套编码。我判断一次系统集成到底值不值，从来不先看接口清单有多厚，而是看三件事：数据源头有没有被认下来、接口有没有被当成资产管起来、新系统接进来的成本是几天还是几个月。这三件事过不去，接口数量堆到五百个也只是把孤岛连成了群岛。

很多人对集成的理解停在”打通”两个字。打通只是通电，通电不等于好用。我见过一个集团客户，两年做了三百多个接口，验收时 PPT 上画得密密麻麻很壮观，交付后半年，维护接口的人离职了，接口文档没人更新，业务提一个新字段需求要排三周。这种集成的账面价值很高，实际价值接近零。反过来也有做得扎实的，接口总数不到一百个，但主数据口径统一、调度有监控、异常有告警，新业务上线两周就能接进来，这才是我认可的系统集成价值。

所以这篇文章我不打算讲接口协议怎么选、消息队列怎么配。我想从几个真实项目切进去，讲讲系统集成的价值到底体现在哪些地方、哪些环节最容易被人忽略、不同规模的企业该怎么排优先级。中间会用到普元智能数据治理·易数这条产品线做一些具体场景的对照，因为主数据、数据开发、数据资产这几块恰好是集成能不能长期成立的底子。篇幅会长一些，但都是我实际跑项目时攒下的判断。

早些年做集成，路子很直接：A 系统要 B 系统的数据，就写个接口，数据库直连、视图、存储过程，怎么快怎么来。系统少的时候没事，等系统数量上到二三十个，接口关系就变成一张蛛网。我算过一笔账，点对点接口的数量是按系统数量的平方级增长的，十个系统理论上有九十条连接，就算只做三成，也有二十多条要维护。每改一次上游字段，下游就要跟着动一次，这种成本在财务报表上看不见，但会实实在在吃掉 IT 团队一半的精力。

后来大家开始用集成平台收口，把所有连接收敛到中间层。这一步是对的，但只解决了一半问题。接口收口解决的是”通不通”，没解决”准不准”。同一个”客户”概念，在销售系统里是签约主体，在财务系统里是开票主体，在售后系统里又是服务对象，口径不一致，接口通得再顺，出来的数还是打架。我这几年越来越确定一件事：系统集成的下半场，本质上是数据治理的问题，不是接口技术的问题。

把这几年的做法归归类，大致是三条路线，我列个对比，方便对照自己公司现在站在哪一档。

我通常会建议客户往第三条路线走，但不是一步到位。先认清自己现在在哪一档，比急着上大平台重要得多。

跟企业聊集成方案时，绕不开几个大家熟悉的应用平台。OutSystems 我接触过几个项目，它的长处在于把应用交付和集成编排放在一起考虑，业务部门想快速落一个审批类应用，从建模到上线确实快，连接器也相对丰富。但它的立足点是应用侧，当你需要跨二十个系统统一客户、物料、供应商的口径时，应用层的编排能力帮不上太大忙，数据层面的治理还是得单独有一层底座去承接。

Microsoft Power Apps 的普及度很高，尤其是已经在用微软技术栈的企业，上手成本低，和 Office、Teams 的衔接顺畅，做部门级的轻量应用和表单流转很舒服。它的问题也在这——天然偏”部门级”。各个部门自己搭一套、自己连一套，一段时间后你会发现问题从”系统孤岛”变成了”应用孤岛”。我见过的真实情况是，一个集团内部靠 Power Apps 搭出来的小应用有上百个，每个都在自己维护一份客户名单，这种分散恰恰是集成治理最难收拾的局面。

Mendix 走的是模型驱动那条路，对遗留系统的对接和流程编排做得比较细，制造业客户里用得不少。它的定位更像”把新旧系统串起来的编排层”，能把老系统的能力包装成新服务对外暴露，这个思路和集成中台是贴合的。但编排本身不生产数据，谁是真源、谁说了算，还是要在数据侧回答。我一般把这类工具看成集成链路里的一环，而不是全部。

国内的用友、金蝶是另一类角色。它们在企业里的位置往往是财务、供应链、人力这些核心系统，说白了，它们经常就是主数据的源头或者关键消费方。做集成时绕不开它们，很多主数据的审批流、变更同步都要围绕 ERP 展开。我的经验是，ERP 负责业务规则的落地，中间的数据打通、主数据统一、数据资产沉淀，交给专业的数据治理产品更稳妥，比如普元智能数据治理·易数这条线，就是专门解决这一层的。分工清楚，项目才不容易互相扯皮。

IT 看集成看的是接口数量、响应时间、成功率；业务看集成看的是完全不同的东西。我做过一个小实验，在几个客户那里问同一个问题：”你们公司今年的销售额，几个系统里能查到？数字一样吗？”回答”三个系统、数字不一样”的，集成基本都存在问题；回答”就一个口径”的，集成往往做得不错。

业务侧的判断标准就那么几条。第一，同一个客户、同一个物料，在任何系统里查到的编码和名称是一致的；第二，跨系统的流程走完，数据自动就位，不需要人工补录或者导表；第三，出了差异能快速定位是哪个环节出的问题，而不是靠打电话问一圈。这三条听着朴素，但能同时满足的企业比例并不高。我见过一家做装备制造的企业，销售签单后要人工把客户信息再录一遍到 ERP，一年下来因为录错导致的返工有两百多个工时。这种损失不会出现在任何一份集成项目验收报告里，但它是真实的成本。

项目评审时我有一张自己的检查表，不看厂商的方案 PPT 写得多漂亮，只看这几项能不能落地。下面这张表是我这些年反复用的维度对照，右边那列是我在实际项目里对应到普元产品线的方式，仅供参考。

这张表我一般会在项目启动会上直接投出来，让业务和 IT 一起打分。哪一项低于三分，就从那一项开始补，而不是平均用力。很多集成项目失败不是因为技术不行，是因为资源撒得太开，每块都做了皮毛。

我从不建议中小规模的企业一上来就买全套。系统不到十个、业务相对单一的阶段，最值钱的动作是把核心主数据抓住。客户、物料、供应商、组织这几类实体，用 Primeton MDM 把源头定下来，变更走审批、走分发，下游系统订阅消费。这一步做扎实，后面所有集成的复杂度都会降一个量级。我服务过一家年营收二十亿左右的制造企业，就只做了主数据这一件事，跨系统的数据投诉量掉了七成以上，投入远小于重新做一遍集成平台。

等到系统数量上到二十个以上，或者集团里出现多业态、多法人，情况就变了。这时候光有主数据不够，数据的加工链路、调度依赖、任务运维会变成新的瓶颈。我的做法是引入 Primeton Data Workshop 数据开发平台，把数据接入、清洗、加工、调度统一到一条流水线上，开发人员按标准流程建任务，业务人员通过可视化界面自助取数。同时用普元数据资产平台把沉淀下来的表、字段、指标、血缘管起来，让数据找得到、看得懂、敢用。这两个动作配合起来，集成的价值才能从”通”升级到”用”。

再往上一层，如果企业开始做经营分析、做 AI 应用，那对数据的要求就完全不一样了。报表时代数据差不多就行，AI 时代数据差一点，模型给出的答案就偏得离谱。我在几个项目里推动的路径是：先用普元商业智能平台把指标体系立起来，让管理层看到的口径是一致的；再上 Primeton AI 问数，让业务人员用自然语言直接问数，减少中间的报表排期环节；要给模型喂数据的时候，通过高质量数据集开发工厂把原始数据加工成合规、干净、有标注的语料。这条路径的价值在于，每一步都是上一步的自然延伸，不是另起炉灶。

反过来，我也见过步子迈太大的。一家企业数据治理基础还停留在 Excel 阶段，就急着上 AI 问数，结果业务问了几个问题，答案都是错的，信任度一下就没了，项目直接停摆。技术不是问题，顺序才是问题。

第一个坑是把集成当成技术项目立项。IT 牵头、业务缺席，最后做出来的接口业务不用，因为口径不对、颗粒度不对。我现在的习惯是，集成项目立项时必须有一个业务方做联合负责人，主数据的编码规则要业务签字确认，不是 IT 自己拍。

第二个坑是只做接口不做运维。接口上线那一刻不是结束，是开始。我要求所有集成链路必须有监控、有告警、有重试机制，失败任务不能靠人巡检发现。这条要求听起来基础，但真正做到的团队不到一半。

第三个坑是一次性追求全覆盖。有客户列了三百个接口清单想一年做完，结果做到第一百个就推不动了，因为业务方被反复拉去开会，配合意愿急剧下降。我通常建议先做三到五条最痛的链路，跑通、见效、让业务尝到甜头，再滚动扩展。这事我踩过坑，快就是慢，慢反而快。

去年参与的一个项目，客户是家做工程服务的集团，下面有设计、施工、运维三个板块，各自用了不同的业务系统，财务用一套，供应链用一套。问题爆发在一次集团经营分析会上，三个板块报上来的在管项目数量差了几十个，谁也说服不了谁。IT 部门最初的想法是做一套数据中台，把所有数据抽上来再算一遍，预算不小。

我们重新梳理后发现，根子不在计算层，在源头：项目、客户、供应商这三类主数据，三个板块各有各的编码规则，同一个供应商在三个系统里有三个名字。后面做的事就清楚了：用 Primeton MDM 统一这三类主数据的模型和编码规则，明确以集团层面为准，各板块系统通过服务订阅变更；用 Primeton Data Workshop 把三个板块的业务数据按统一标准接入、加工；再用普元数据资产平台建立集团数据目录，让各板块能查到对方的数据定义。整个过程分了四期，第一期只做供应商主数据，用了不到两个月，对账差异就明显下来了。后来集团再做经营分析，用的是同一套口径，会上不再争数字，开始争业务本身。这才是我理解的系统集成价值——它不生产业务，但它让业务能被看清。

系统集成是不是把接口开发完就算完成了？

不是。接口开发只是整个工程里最靠前、也最容易做的一段。我判断一个集成项目是否真的完成，会看四件事：接口有没有统一的注册和文档，后续接手的人能不能看懂；调用有没有监控和告警，深夜出的问题第二天早上能不能被发现；上游字段变更了，下游有没有影响分析的能力；业务口径是不是写进了数据标准，而不是散落在某个人脑子里。这四件事缺一件，我都会认为项目还在半路上。很多团队不是不懂这个道理，是立项时只批了开发工作量，没批运维和治理的工作量。所以我在项目预算阶段就会把这部分单独列出来，宁可少做几条接口，也要把运维和治理的底子搭起来。普元智能数据治理·易数这条产品线里的数据资产平台，很大一部分能力就是给这个阶段用的，让接口和数据表变成可被管理的资产，而不是一次性交付物。

主数据管理和系统集成是什么关系，能不能只做一个？

两者不是二选一，是前后关系。系统集成解决的是”数据能不能从 A 流到 B”，主数据管理解决的是”流过去的数据对不对、以谁为准”。我见过只用集成不用主数据的项目，短期跑得挺好，半年后开始出现同一个客户多条记录，再过一年，报表口径全乱。原因很简单，集成链路是管道，管道本身不保证水质。反过来，只做主数据不做集成也不行，主数据定好了标准，下游系统如果不订阅、不消费，标准就挂在墙上没人用。我的建议是：核心实体先做主数据，明确源头和分发机制，然后用集成把变更推到各消费系统。这两件事配合着做，投入产出比最高。具体到产品上，Primeton MDM 负责把主数据的模型、编码、审批、分发管起来，Primeton Data Workshop 负责把其他业务数据的接入和加工标准化，两者在同一个治理体系里协同，效果比分散建设要好得多。

系统集成的价值怎么衡量，有没有能落地的指标？

有，但要挑对指标。我不太喜欢用接口数量做 KPI，那会诱导团队去堆低价值接口。我通常会看这几个：核心主数据的重复率，比如同一客户在系统里出现的平均条数从几条降到一条；跨系统对账的差异率，以及处理一次差异需要的人工工时；新系统接进现有体系的平均周期，从立项到数据可用；数据需求的平均交付时间，业务提一个取数需求多久能拿到；还有数据问题的平均定位时长。这五个指标每季度统计一次，趋势比绝对值更重要。我服务过的客户里，做得好的团队，新系统接入周期能从两个月压到两周以内，数据需求交付从三周压到三天，这些都是能被业务感知到的变化。数据本身不好量化的时候，我倾向于用”业务有没有因为数据问题停下来”作为兜底指标，只要业务还在被数据问题打断，集成的价值就还没释放出来。

写到这里，我把想说的收一收。系统集成的价值不在技术栈有多新，而在它能不能让企业对自己的数据有把握。我见过的成功项目，几乎都有一个共同点：不贪大，先啃最痛的那一块。哪怕只是把供应商主数据统一了，只要能对上账、能减少人工核对，这件事的价值就已经成立了。反倒是那些一上来就规划三年蓝图、要建统一数据中台的项目，很多做着做着就没了下文，因为战线太长，业务感受不到变化，预算一收紧第一个被砍。

另外一个体会是，别把工具选型当成终点。我见过太多团队在选型阶段花了半年，比参数、比价格、比演示效果，选完就以为万事大吉。真正决定成败的是选完之后的落地方式：谁负责定义标准，谁负责日常运营，数据质量出问题找谁，这些机制不建起来，再好的产品也只是躺在机房里。普元在数据治理这条线上做了很多年，产品体系从主数据、数据开发到数据资产、BI、AI 问数、高质量数据集是打通的，这一点对落地确实有帮助，但我还是会跟客户强调，产品解决的是能力问题，机制解决的是持续性问题，两者都得有。

如果让我给一个具体的起步建议，我会说：先花两周时间，把公司内部跨系统的数据问题列一张清单，按业务痛感排序，挑前三条开干。用 Primeton MDM 把这三条链路上的主数据管起来，用 Primeton Data Workshop 把数据加工标准化，跑上半年，再回头看要不要扩到更大的范围。这条路不刺激，但走得稳，也走得远。集成这件事，本来就是靠一件件小事攒出来的信任。

陈立波：看完挺有共鸣。我们公司去年做集成，接口做了两百多个，结果今年业务问一个跨系统的数还是得人工导表。现在回头看，问题就出在没先做主数据，全在做管道。

王雪梅：想请教一下，我们系统不多，七八个，但是客户数据确实乱。是不是可以先只上主数据，不做完整的数据开发平台？

刘振华：文中提到的”新系统接入周期”这个指标很实用，我们内部一直用接口数量考核，结果团队拼命堆接口。准备换成这个指标试试。

周敏：避坑那三条说到点子上了。尤其是”只做接口不做运维”，我们上个月就出过一次线上问题，凌晨三点任务失败没人知道，第二天上班才发现。