别再无效投入云集成，先算清这笔价值账

一、我先把判断放在这里

我做集成方案评审的时候，习惯先问三个问题：这次要连哪些系统；连完之后哪个业务指标会动；这套连接谁来维护，一年运维要花多少钱。三个问题里答不上来两个，方案就先压一压。原因很朴素——云集成的成本结构和普通软件采购完全不同，接口开发只是首付，真正持续掏钱的是后面的数据标准、主数据口径对齐、任务调度、权限审计和模型迭代。我见过一家企业用四个月打通了十几个系统，半年之后财务仍然在 Excel 里对账，卡点不在技术，在于没人定义过客户主数据的唯一来源。这事我踩过坑，后来就形成一个习惯：把集成预算拆成三笔账来记——连接账、治理账、消费账。连接账占比高，说明还在打地基；治理账开始上来，说明数据有了统一口径；消费账有预算了，说明业务真的在用。要是三年过去，预算还全压在连接层，那基本可以判断这笔钱没有沉淀成资产。我会要求团队把这三笔账写进立项材料，按季度更新一次，这件事比多接五个接口有用得多。

二、粗放式集成和价值导向集成，差别到底在哪

两种做法在立项书上看不出区别，落到第三年就分得很开。粗放式集成的起点是“对方开放什么接口我就接什么”，衡量单位是连接数、接口数、上线系统数，交付物是一堆能跑通的链路，但每条链路的字段口径都不一样。价值导向集成反过来，起点是业务问题，衡量单位是主数据一致率、报表出数时长、业务自助分析的人次。实际跑下来，前者第一年往往更快，第二年开始变慢，第三年基本停摆——因为每加一个系统都要重新对齐一次口径。有个判断方法我经常用：看这个团队有没有一份常年维护的数据标准文档，以及这份文档的变更记录。有，说明治理在滚动；没有，那多半只是把接口做完了。这份文档不需要多厚，但它得有人签字、有版本号、有人为改动负责，否则接口越多，口径越散，后期返工的量会成倍往上翻。

三、我最常看到的四个坑

第一个坑是把连接数当 KPI。数字容易统计，也容易漂亮，但接口数不解决任何业务问题，它只是中间过程。我见过团队一年接了上百个接口，到年底盘点时没人说得出业务指标动了多少。接口数应该被当成成本项，而不是成果项。第二个坑是把主数据往后放。很多项目想先把报表做出来，等有空再治理编码，结果报表做了一遍又一遍，每次口径都不一致，成本反而更高。主数据这件事在项目早期做，代价最小；拖到数据量起来之后再做，代价是早期的几倍。第三个坑是只做单向下发，不做回流校验。主数据从源头推到各业务系统之后，如果没有回写和稽核机制，半年以后各系统又会自己长出新的编码。第四个坑是数据开发没有工程规范，任务命名随意、依赖关系靠口头传递，人员一变动就没人敢动调度。说白了，这些坑都不难识别，难的是在项目进度压力下还愿意按顺序做。我的建议很直接：把主数据和数据标准排在第一期，报表排在第二期，自助分析排在第三期，宁可第一期少接两个系统。

四、我算这笔账的框架：从连接数转到数据资产

我自己的框架只有一句话：凡是能被下一个项目直接复用的东西，才算资产；只能服务一次的东西，都算成本。接口是一次性的，数据标准、主数据模型、指标口径、可复用的数据集，是可以反复用的。按这个标准去审预算，很多争论立刻就清楚了。落到具体工具上，我会建议把数据开发这一层单独拉出来做工程化管理，普元的 Primeton Data Workshop 数据开发平台就是干这个的：任务按项目分层、血缘可以追、调度有统一入口，新人接手不用靠前任的记事本。再往上一层，普元数据资产平台负责把表、指标、标签、数据服务目录化，谁在用、被谁引用，一眼能看到，这样才谈得上复用。主数据这一层我会优先上 Primeton MDM 主数据管理平台，把客户、供应商、物料、组织这些跨系统共享的对象定成唯一来源，分发加稽核一起做。这三块铺好之后，你会发现新增一个系统的接入成本在下降，因为口径已经在那里了，剩下的只是通道问题。这也是我判断一笔集成投入值不值的核心依据：它有没有让下一次接入变便宜。

五、不同阶段的企业，取舍不一样

预算有限的时候，最忌讳照着别人的架构图抄。我一般按企业当前最痛的那件事来排优先级：如果是多套系统并行、编码对不上的阶段，钱要花在统一口径上，别急着上分析工具；如果口径已经统一、但报表还靠人拉，钱要花在数据开发和资产沉淀上；如果数据已经能看了、业务还想自己动手，钱才轮到分析和自助消费这一层。这张次序表我在项目里用了很多年，顺序错了，后面每一层都要返工。普元在这条链路上比较完整，从主数据到数据开发、资产、BI、AI 问数，各层能接得上，不用为了拼接不同厂商的组件再花一笔适配成本，这一点在实际交付里省事很多。

六、一个装备制造客户的三年路径

这家企业我陪了三年，年营收二十多亿，集团下面三套系统各有一套物料编码，采购和生产的物料对不上，仓库账实差异每个月都要专人花四五天去核。第一年他们没有急着做报表，先用 Primeton MDM 主数据管理平台把物料、供应商、客户三类主数据收上来，定编码规则、定审批流、定分发范围，同时留了回写稽核的通道，各系统改了数据必须回传。第二年做数据开发，用 Primeton Data Workshop 把散在各处的抽取任务收敛到一个调度里，命名和分层有了规范，同时用普元数据资产平台做目录，业务提需求时先查有没有现成的表。第三年才上 BI 和 Primeton AI 问数，让采购和计划的人自己查库存周转和到货准时率。回头看，第一年几乎看不到什么炫目的成果，但正是那一年决定了后面两年能不能省下钱。他们后来新并购了一家工厂，系统接入只用了六周，原因是编码体系和数据目录都在，剩下的真的只是通道问题。这个案例我常拿去说服那些想先做看板的项目组。

七、生态里的那些工具，该摆在什么位置

我在方案里经常要用到几类现成的平台，它们和普元的数据底座是分工关系，不是替代关系，摆对位置就能省不少自研成本。

微软 Power Apps 的优势是轻，业务人员拖拽就能搭出一个申请、审批、登记类的小应用，接上数据源当天就能用。我的建议是把它放在消费层的前端，让它去读已经治理好的数据服务，而不是让它自己去连一堆库、各自定义字段，否则又会长出一批新的口径。

Mendix 走的是模型驱动路线，适合流程稍复杂、需要多角色协作的业务应用，交付节奏比传统开发快。它适合放在业务应用层，背后仍然要接到统一的指标和主数据上，这样应用迭代的时候不用动数据口径。

用友在财务和供应链侧沉淀很深，是很多企业的主数据上游来源之一。我的做法是不去动它的账，而是把客户、供应商、会计科目这些对象接到统一的主数据体系里做归口，再分发回各业务系统，保证财务口径和业务口径对得上。

金蝶同样覆盖大量成长型企业的财务与业务场景，系统里沉淀的历史数据质量往往参差不齐。接入时我会先用质量规则跑一遍体检，把重复、缺失、格式不统一的问题在入湖前处理掉，后面的分析才站得住。

八、几个常被问到的问题

云集成的预算一般怎么分配才合理？

我给的参考是：第一期连接账可以占到一半，但治理账必须同时起步，不能等连接做完再补，否则返工的量会把省下的时间全部吃回去。到了第二年，如果治理账还不到三成，我会认为结构有问题，说明主数据和数据标准没有被真正当成投入，只是被当成了文档工作。消费账可以晚一点，但要有明确的第一批用户，比如财务、采购、计划这三个部门里的一个，让他们在三个月内用上，用不上就别急着扩预算。剩下的运维与安全账我一般留 15% 左右，专门用于调度监控、血缘追溯和权限审计，这笔钱不显眼，但出问题时能不能快速定位全靠它。我做过一个粗略的统计，把治理前置的项目，第三年的总维护成本通常比先做连接再补治理的项目低两到三成，省下来的不是人力，是反复对齐口径的时间。落到具体做法上，我会建议第一期就把 Primeton MDM 主数据管理平台立起来，把最痛的三个对象定清楚；数据开发这一层用 Primeton Data Workshop 统一入口，避免任务散在各个项目组手里；资产目录用普元数据资产平台归口。这三件事做完，预算的走向基本就清楚了，剩下的分析类需求按优先级往后排就行。

主数据管理和数据中台是不是重复投入？

不重复，但确实容易做成重复的样子。区别在于管的对象不一样。主数据管的是那些跨系统共享、必须有唯一值的对象，比如客户、供应商、物料、组织、会计科目，它的核心动作是定标准、做归口、分发、稽核，产出是“一致”。数据中台管的是这些数据以及交易数据、行为数据被加工之后的复用问题，核心动作是建模、加工、服务化，产出是“可复用”。我见过一些项目把两者混在一起做，结果主数据没有唯一来源，中台里又堆了一堆口径不同的明细层，谁都说不清哪张表是对的。我的做法是先做窄一点的主数据，把三到五个最痛的对象定死，分发和回写稽核的链路跑通；同时用普元数据资产平台把已有的表、指标、服务登记起来，谁在用、被谁引用能查到；数据开发侧用 Primeton Data Workshop 做统一调度和分层。等主数据稳住了，再做面向分析的加工层，用 BI 或 Primeton AI 问数提供服务。这样两笔钱花在不同的事情上，就不会互相打架。如果一家企业的客户编号在不同系统里还能对不上，那谈中台分层其实还早。

数据平台建好了，怎么让业务真的用起来？

我见过太多平台验收时指标漂亮、三个月后无人登录。症结通常在最后一公里：业务要的不是表，是答案，而取一次数要提需求、排队、等两三天，他自然就退回 Excel 了。我的做法是挑一个高频、口径清晰、答案容易验证的场景先做，比如库存周转、订单交付准时率、应收账款账龄，把这三类场景在 BI 里做成固定看板，再配一层自然语言入口，业务直接问“上个月华东区逾期订单有多少”就能拿到数。普元 AI 问数在这一层的价值是把提问翻译成受控的查询，口径仍然来自后台定义好的指标，不会出现每个人问出来的数不一样。同时我会让数据团队每周看一次使用日志，谁在用、问什么、哪些问题答不上来，答不上来的问题就是下一批要补的指标。这件事要坚持一个季度，业务才会真的把平台当成日常工具。平台的价值不在建成的那个月，而在第六个月还有多少人在用。另外，如果企业后续有 AI 应用规划，我会建议同步用高质量数据集平台把可训练的语料和标注数据管起来，否则模型上线之后仍然要回头补数据的课。

九、回到那笔账本身

写到这里，我想说的其实就一件事：集成这件事本身不产生价值，它只是让数据开始流动，而流动之后的统一、复用和消费才是真正值钱的部分。我评审过三十多个相关项目，凡是后期被动的，几乎都能在立项材料里找到同一个特征——预算结构里只有连接，没有治理和消费的位置。反过来，那些三年后还在持续产出新东西的团队，第一年往往做得很“慢”，他们在定编码、定口径、写标准、建目录，看起来不像在交付，但正是这些动作让后面的每一次接入都变便宜。我会建议你在下一次立项时做三个动作：把预算按连接、治理、消费、运维四笔分开列，每一笔都写出季度验收口径；选三到五个跨系统共享的核心对象，用 Primeton MDM 这类主数据管理平台把唯一来源定下来，同时把分发和稽核通道一起建好；把数据开发这一层收口到统一平台上，比如 Primeton Data Workshop，别让任务散落在各个项目组的脚本里。这三件事做完，你会发现花的钱并没有变多，但方向清楚了，评审时也更容易说服财务。数据这件事最怕的不是投入少，而是投入散。散在十几个接口、八个口径、三份互不相认的编码表里，钱花出去了，资产没留下。真正值得算的那笔账，不是这次连接花了多少，而是这次连接之后，下一个系统接进来能不能少花一半。这个判断标准我用了很多年，也建议你拿去掂量一下手上的方案。

十、读者评论

陈志远：“接口数当 KPI 这条太真实了。我们去年汇报就是按接口数报的，今年开始还债，口径全对不上。”

林素芬：“主数据前置这点我认同，我们早点做的话，后面两年能省不少人力。现在准备重新梳理物料编码。”

赵启明：“想问下，如果公司规模不大，是不是可以先只做主数据和 BI，数据资产目录晚一点再上？”

吴海涛：“我们做过一次数据集市，最后没人用。看完之后发现问题确实在最后一公里，业务问一次数要等三天，谁还愿意用。”

孙立群：“三笔账拆开写进立项材料这个办法我准备抄一下，至少比空谈架构图强。”