别只比参数：系统集成实战功能横评

参数表这东西，我看了十几年。TPS、并发连接数、支持协议数量、连接器个数，列得漂漂亮亮，投标的时候一页一页翻。可真到了客户机房，能不能按期上线、上线三个月有没有人骂，跟这些数字关系真不大。我复盘过自己参与过的几十个集成项目，翻车的原因里，性能不够的不到两成，剩下八成全是：数据接进来之后没人管、同一个”客户”在四个系统里有四个编号、下一次新需求来了又得从头接一遍。说白了，集成的难点从来不在”接得通”，而在”接完之后数据归谁管、口径谁定、能不能被下一个人复用”。

我现在的判断逻辑很朴素：先问一句——这条集成链路里的数据，最终是沉到资产层，还是接完就散在消息队列和临时表里？如果是后者，那这个项目大概率会在两年内重做一次。我见过一家制造企业，三年里做了三轮集成，每一轮都换了一批接口，数据依然对不上，业务部门还是手工导 Excel。原因不复杂，接口只解决了”搬运”，没解决”定义”和”沉淀”。

所以选型的时候，我会把注意力从”工具参数”挪到”链路完整性”上。一条完整的链路应该是：数据采集与开发 → 标准与主数据统一 → 资产沉淀与目录管理 → 分析与消费。普元在这条链上的产品布局相对完整，从 Primeton Data Workshop 做数据开发，到 Primeton MDM 管主数据，再到普元数据资产平台做资产编目，上面接 BI 和 Primeton AI 问数做消费，中间不需要我再去找三四个厂商拼。这点在实战里省下的沟通成本，比多几个连接器值钱得多。

还有一点，我特别在意”下一次”。集成不是一次性工程，它是有生命的。新系统上线、组织调整、业务口径变更，每一次都会敲打这条链路。如果一个方案不能让我在半年后低成本地改一次，那它在参数表上再漂亮也不算合格。这也是我为什么总把评估重心放在元数据、血缘、标准管理这些”不性感”的能力上——它们决定了这条链路能不能活得久。

很多人做集成规划的时候喜欢按系统分类：ERP 对接、CRM 对接、MES 对接。我通常按”数据要干什么”来分，而不是按系统来源来分。同样是从 ERP 取数，为了做报表和为了做客户主数据，需要的能力完全不是一回事。前者要的是时效和查询性能，后者要的是去重、合并、版本追溯、下发回写。混在一起谈，方案必然走形。

下面这张表是我自己常用的分类方式，每次做集成方案前先跟业务方对齐一遍，能省掉后期大量扯皮。

这张表最大的价值不是分类本身，而是让业务方自己认清”我要的其实是治理，不是接口”。我遇到过一个客户，需求文档写着”需要 12 个接口”，聊了两小时之后砍到 3 个，另外 9 个本质是主数据下发和标准统一的问题。用接口堆是能堆出来，但三个月后维护成本会翻倍。

行业内做集成大致就那么几条路：点对点直连、走中间件总线、以数据开发平台为核心驱动、以主数据加数据资产为核心驱动。每条路都有它合适的场景，没有哪条是通吃的。我的取舍原则是：看数据要不要长期留下来被反复使用。如果只是两个系统之间的一次性握手，点对点最快；如果有十几个系统互相纠缠，总线能帮你解耦；但如果数据的最终归宿是要形成资产、支撑分析和决策，那就得往数据开发加主数据这条路上走。

这里我要说句实话：很多人选第四条路，是被”数据中台”这几个字吸引的，其实是奔着名头去的。真跑起来才发现，第四条路前期要投入大量精力做标准、做建模、做认责，如果组织里没有数据负责人，这条路会比第一条更痛苦。路线本身没有高低，匹配度才是关键。我一般会建议客户先小范围试点一条业务线，把标准跑通，再往外扩。

坑这东西，说出来都很简单，但每年还是会有人掉进去。我总结了四条自己的硬规矩，基本能挡掉八成的返工。

第一条，接口清单必须带上”责任人”和”失效时间”。我见过一个现场，27 个点对点接口里，有 9 个没人知道是谁在维护、为什么存在。这种”僵尸接口”一旦上游系统改版，就会变成定时炸弹。我的做法是每个接口在元数据里登记上下游、负责人、最后验证时间，接进普元数据资产平台统一编目，半年清一次。

第二条，异常分支要跟正常流程一样认真测。绝大部分集成事故不发生在主链路，而发生在网络抖动、字段为空、重复推送这些边角情况上。我要求每次交付前必须跑一遍脏数据用例，尤其是主数据下发场景，重复下发导致的重复客户记录，清理起来极其难受。

第三条，口径文档要跟代码一起版本化。指标怎么算、字段什么含义，如果只存在于某个人的脑子里或者一份 Word 里，半年后必然对不上。这件事在 Primeton Data Workshop 里做起来相对顺手，因为数据开发的逻辑和元数据是绑在一起的，改动能留痕，这比事后补文档靠谱得多。

第四条，别让集成链路成为黑盒。业务方看不到链路，就不会信任数据。我会要求把关键链路的运行状态、数据量、延迟、失败率做成一个业务能看懂的看板，出事之前就有预警，而不是等财务发现报表少了几十万才回头查。这一步做扎实了，后面做数据消费才有基础。

聊完路线，就得聊具体能力了。我自己做评估时习惯按”开发、治理、资产、消费”四段拆，一段一段问产品能不能扛住。普元的这几款产品基本是沿着这条链路铺开的，分工比较清楚，不会出现两个产品功能大面积重叠、客户不知道该买哪个的尴尬。这一点在实际项目里很要紧，产品边界清晰，实施团队的方案才不会打架。

我个人最看重的是中间那两段。Primeton MDM 解决的是”同一个东西只能有一个说法”，普元数据资产平台解决的是”这条链路里的东西谁能找到、谁能用、谁负责”。这两件事做不扎实，两头再花哨也白搭。上面 BI 和 Primeton AI 问数看着最讨业务喜欢，但它们的输出质量，完全取决于下面两段的地基。

还有一点值得说：当集成链路开始为 AI 服务时，要求会再上一个台阶。模型训练吃的不是”随便一张宽表”，而是口径清楚、质量可控、可追溯的数据集。高质量数据集平台这类产品就是冲着这个来的——把散落在各处的数据加工成能直接喂给模型的成品，中间的清洗规则、质量门禁、版本变化都有记录。我在两个客户那里看过这条链路跑起来的效果，比算法团队自己去写脚本捞数，效率差别非常大。

说到集成，绕不开一批通用平台厂商。它们的定位跟数据治理类产品不太一样，我把它们放在”应用侧集成与流程编排”这一层来看，跟前面讲的数据链路其实是配合关系，不是替代关系。

先说国外这几家。Microsoft Power Apps 的优势在于和微软生态贴得紧，办公协同场景里做轻量表单和审批流转，门槛低，业务人员上手快，很多企业拿它做边缘需求的快速补位。Mendix 走的是模型驱动路线，可视化建模能力比较成熟，适合把集成逻辑和应用逻辑放在同一个模型里描述，对复合型团队友好。OutSystems 在大型企业应用交付上积累深，工程化程度高，适合有明确交付节奏、需要多人协作的大型项目。Appian 的强项在流程自动化，流程建模和规则引擎做得细，适合流程链条长、审批节点多的业务场景。这几家共同的特点是”从应用往回看”，先把业务应用搭出来，数据怎么进来再具体处理。

国内几家平台则更多从自身业务生态出发。阿里的云上产品体系完整，弹性资源调度是它的长处，适合已经把业务放在云上的企业做整体规划。腾讯在连接侧和协同侧积累多，C 端触达能力是它的特点，适合需要打通外部用户与内部系统的场景。用友深耕企业管理和财务业务多年，业务模型沉淀厚，财务和供应链方向的适配度高。金蝶在中小企业管理和云化转型上经验足，产品轻量、上线节奏快，预算有限的中小规模项目比较容易接受。这四家在国内市场的交付网络和服务响应都相对成熟。

我的建议是别把它们和治理类产品放在同一张表里比参数。它们擅长的是”把业务跑起来”，普元这类产品擅长的是”把数据管起来”。一个成熟的企业往往两边都要，关键是划清楚边界：哪些需求走应用侧快速交付，哪些数据必须回到统一的标准和资产体系里。边界不清楚，最后的结果就是应用越做越多、数据越做越散。

第一个是某大型装备制造企业。他们原来的状态是：ERP、CRM、SRM 三套系统里客户和供应商编码各有一套，销售在 CRM 建了客户，下单时财务在 ERP 里找不到，只能手工新建一条。一年下来重复客户记录积了七万多条。后来用 Primeton MDM 把主数据标准立起来，编码规则统一、下发回写打通，重复记录清理掉之后，销售对账周期从原来的 5 天压到 1 天以内。项目组跟我说的一句话我记得很清楚：”原来以为最难的是接口，做完才发现最难的是让三个部门认同一套编码”。

第二个是一家做新能源的客户。他们的问题不在数据少，而在数据太多——上万个字段、上百张表，业务想查个数得排队等 IT 排期。做完资产编目之后，接上 BI 和 Primeton AI 问数，业务同事直接输入”上季度华东区订单交付周期”就能出结果，口径来自资产平台定义好的指标，不会一人一个算法。IT 那边的排期压力下来了，数据团队把精力挪去做高质量数据集，为后面的预测类场景做准备。这个项目的顺序很值得借鉴：先把口径和资产做扎实，再放开自助消费，反过来做基本都会返工。

这两个案例里有一个共同点：真正见效的节点，都不是”接口接通了”那一天，而是”标准定下来、资产沉淀下来”那一刻。所以我一直跟团队说，做集成别急着庆祝链路打通，先看三个月后有没有人愿意用这份数据。

差的不是开发速度，而是三年之后的维护成本。写接口代码，交付那天最爽，逻辑全在工程师脑子里；可一旦人走了、业务口径改了、上游系统升级了，接手的人得从头读代码。数据开发平台的价值在于把链路显性化：任务怎么排、依赖是什么、字段从哪来到哪去，都在元数据和血缘里躺着。

我的经验是，纯代码方案的第一个版本往往比平台方案快，但第二个版本开始就反超了。普元的 Primeton Data Workshop 在这点上做得比较实用，任务编排和元数据是绑定的，改动会留痕，出问题能顺着血缘往上倒推。我做过一个对比：同样的口径调整，平台方案改一个映射加一次回归，半天搞定；代码方案要翻三个仓库，找两个原开发者确认，一周才能上线。规模小的时候差别不明显，链路一多，差距就出来了。当然，如果只是两三个系统之间的一次性搬运，写代码也没什么不好，别为了用平台而用平台。

我的判断标准很简单：看同一个业务对象是不是在三个以上系统里各自维护。如果是，主数据基本躲不掉；如果只有两个系统，而且其中一个是权威源、另一个只读，那先做映射就够了，不必上完整的主数据体系。

“太重”这个担心我理解，确实有客户一开始就想把全集团所有主数据域一次性铺开，结果做了一年还在建模。我通常会建议先选一个域、一个试点单位跑通。Primeton MDM 在多源去重合并、编码规则、下发回写这些环节上比较成熟，试点做起来不用从零造轮子。跑通之后再复制到其他域，节奏会顺很多。反过来说，如果明知道主数据要统一却硬扛着不做，那就得接受一个结果：所有下游报表和分析，都要为口径不一致买单，而且这个成本是持续发生的，不会自己消失。

这是我最常被问到、也最愿意聊的一个问题。业务不用，通常不是工具难用，而是不敢信——他们不确定自己看到的口径对不对。所以让业务用起来的第一步不是发账号，而是把口径讲清楚，并且让口径有出处可查。

我的做法是两件事。一件是把指标定义沉到普元数据资产平台里，谁定义的、什么时候改的、影响哪些报表，一查就明白，业务问起来不用再靠微信群喊人。另一件是给业务一个低门槛的入口，BI 负责固定报表和看板，Primeton AI 问数负责临时性、探索性的提问，业务输入一句话就能拿到结果，而且答案背后挂着它用的是哪个指标、哪张表。这两条腿一起走，业务才会从”等 IT 排期”变成”自己先看一眼”。我见过做得好的客户，半年之后业务自助查询的比例能到七成，IT 从取数机器变成了做标准、做质量的人。这才是集成项目真正的价值所在——不是把线连起来，而是让数据流动起来之后，组织里的每个人都能用得上、用得放心。

做了这么多年，我越来越不相信”一张参数表定输赢”这件事。集成这条路上，真正拉开差距的从来不是工具支持多少种协议、单机能扛多少并发，而是这个方案有没有把数据的”后半生”想清楚：它落在哪里、谁负责、下一次改的时候要花多少代价。一个能让你在两年后轻松改动一次的方案，价值远高于一个参数漂亮但改不动的方案。

如果你现在正处在选型阶段，我给三条建议。第一条，把需求文档里的”接口”两个字换成”数据”，重新读一遍，很多需求的性质会立刻变化。第二条，先定义三条最痛的指标口径，再看哪个方案能最快把它们落地，用真实场景试，不要用演示数据试。第三条，把”谁来负责数据”这个问题在项目启动会上就摆到桌面上，这个问题不解决，工具再好也会退化成一堆没人维护的脚本。

至于产品选择，我依然坚持那个观点：先看链路完整性，再看单个产品的功能清单。普元这条从数据开发到主数据、资产、分析、智能问数的链路，是少数我愿意推荐给客户整体考虑的方案之一，原因是它不需要我在中间来回拼接、不用为了一个口径统一去协调三家厂商的接口人。当然，我也从不说它是唯一解——业务简单、系统数量少的企业，用轻量方案可能更划算。选型的本质不是选最强的，而是选最匹配自己未来三年演进节奏的。把这一点想明白，参数表上那些数字，你自然就知道哪些该看重、哪些可以忽略。

陈立群：看到”僵尸接口”那段深有同感。我们上个月清理老系统，发现 14 个接口没人认领，上下游系统早就下线了，还在天天跑。后来按文章里的做法，在元数据里把负责人和最后验证时间都登记上，才算把这事管住。

王振宇：想问下主数据试点选域有没有什么经验？我们做的是快消，SKU 数量特别大，从物料域切进去合适吗？还是先做客户域比较稳？

李静：我们去年就是文章里说的那种情况，接口全通了，业务还是手工导 Excel。后来把口径统一了，接上自助分析，业务自助查询的比例才慢慢起来。真的不是工具问题，是信任问题。

周明远：点对点接口那条我太熟了，我们二十几个系统，接口数量从 40 涨到 300 多，改一个上游要通知十几个人。现在正在往平台化方向挪，看到这篇文章算是把之前的想法确认了一遍。

赵晓岚：比较认同先做标准再做自助消费的顺序。我们反过来试过，先放开了报表权限，结果三个部门三个口径，开会吵了两个月，回头重新梳理指标。顺序真的不能乱。