破除信创iPaaS迷思：回归业务本质

我在企业集成和数据治理这条线上做了十几年，从早期的 EAI、ESB，到后来人人都在谈的 iPaaS，再到眼下信创环境下的国产化替换，看过的项目不下几十个。我的判断很直接：信创环境下真正决定项目成败的，不是接了多少个接口，也不是平台支持多少种协议，而是数据能不能被业务直接复用。

这话听着像口号，落到验收现场就非常具体。业务部门不关心你用了什么中间件，他们只问三件事：昨天那批订单为什么没同步过来？客户编码为什么三个系统里不一样？我想要的报表为什么还得让 IT 导数据？这三个问题，没有一个是”接口不够多”造成的。

我见过一些项目，把”接口数达到 500 个””完成 200 套系统的替换”写进验收标准，上线三个月后运维团队天天救火。原因不复杂：那些接口是点对点翻译出来的，没人管字段口径，没人管主数据唯一性。接口越多，理解成本越高，改一个字段口径要动十几个服务。

我的主张这些年没变过：替换是技术动作，集成能不能撑住业务是数据动作。先把主数据、编码规则、数据资产目录理清楚，再谈服务编排和平台选型，顺序反了，投入基本要翻倍。普元在这条路上给的思路，是从主数据和数据资产出发去反推集成设计，而不是先画一张漂亮的架构图，再往里填系统。下面几节我把常见的几个误解拆开讲，也会说清楚什么体量的企业该走哪条路。

第一个变化是关注点从”组件替换”转到”业务连续性”。早几年做信创，甲方给的清单是数据库、中间件、操作系统一项一项打勾。这两年不一样了，清单还在，但验收会上问的都是”切换那天订单能不能正常流转””月底结账会不会卡住”。技术替换是可计划的，业务中断是不可接受的，项目天平自然就往业务那头偏。

第二个变化是接口治理被重新拿出来讲。很多企业在前一轮信息化里攒了几百上千个接口，文档缺失、责任人离职、字段全靠猜。信创改造一动，这些接口全要重测，代价一下就显出来了。我通常会先做一轮接口盘点，把能收敛的收敛掉，能合并的合并掉，再动替换。

第三个变化是数据部门开始坐到集成项目的主位上。以前集成项目是 IT 基础架构团队牵头，现在越来越多是数据团队牵头。为什么？因为大家发现，接口通不通是表象，数据对得上对不上才是命门。

这张表我一般会拿给客户的信息化负责人看，不是为了卖东西，是为了对齐预期。大部分企业以为自己卡在第二阶段，实际问题是第三阶段没做完。底座搭得再漂亮，物料编码在五个系统里是五套，集成永远只能做”翻译”，做不成”共享”。

这些年我在各种评审会上听到过太多相似的话，有些是厂商说的，有些是企业自己说服自己的。我不想逐个点名，只把最影响决策的三条拎出来。

第一条是”上了平台，集成就自然好了”。平台只是容器，它不会替你决定客户编码该用哪个系统的口径。没有主数据标准，平台越大，混乱被放大得越快。

第二条是”接口越多，说明打通得越彻底”。这个逻辑反了。接口数量的增长往往是设计不足的证据，不是成果的证据。一个规范的主数据服务，能替掉十几个点对点同步。

第三条是”数据中台能解决一切”。中台是个组织概念加技术组合，不是一个能自动出结果的盒子。没有业务责任人认领的数据，进了中台也只是换了个地方躺着。

这张对照表我一般放在项目启动会的材料里。先把预期校准，比后期反复返工便宜得多。信创项目的时间窗口通常很紧，返工一次就可能顶掉整个季度的预算。

我复盘过不少失败的集成项目，技术原因占比其实不高。真正的堵点集中在四个地方：一是主数据不唯一，同一个供应商在采购、财务、合同系统里是三个主体；二是口径不统一，营收这个指标三个部门三个算法；三是元数据缺失，字段叫什么、谁负责、什么含义，全靠问人；四是历史数据质量差，迁移时才发现一半记录无法关联。

这四个问题有一个共同特征：它们都不是靠加一层中间件能解决的，必须靠治理动作解决。这也是为什么我常建议客户，先把普元 MDM 这类主数据管理能力立起来，把客户、物料、供应商、组织这几类核心对象的唯一编码定死，再去设计服务。

主数据一旦统一，集成的形态会明显变化。原来是 A 系统推给 B 系统、B 再推给 C，一条链路断在哪都要查三天。现在是各系统向主数据看齐，谁有问题谁对齐，链路短了，责任也清楚了。这个转变，实际跑下来至少能省掉三成以上的接口工作量。

每次接手信创集成相关的项目，我都会拉着业务和 IT 一起过一遍六件事，过不去的就得先补课。

第一件，核心业务对象有没有唯一编码，谁维护，变更流程是什么。第二件，关键指标的统计口径有没有书面定义，有没有版本。第三件，现存接口有没有清单和责任人，近一年调用量排前二十的是哪些。第四件，切换窗口期内业务能不能接受短时中断，能接受多久。第五件，数据质量问题由谁认领，出问题多久内闭环。第六件，这套能力上线后谁运营，是临时项目组还是常设团队。

这六件事听着琐碎，但我见过的返工，八成都能追溯到某一件没问清楚。尤其第六件，很多企业项目验收完团队就散了，半年后系统没人会调，只能重新找厂商。

顺带说一句，第三件事里那份接口清单，我通常会让团队用普元数据资产平台做出的资产目录来对照。哪些接口承载的是主数据分发、哪些是交易明细、哪些其实是报表取数，分类清楚了，收敛方案自然就出来了。

我从不建议一套打法套所有企业。年营收几十亿、系统数量上百套的集团，必须先把主数据和资产目录立起来，再谈服务治理，否则后面每一步都在还债。中等规模、系统二三十套的企业，我的建议是抓核心场景，比如订单到交付、采购到付款这两条主干链路，先打通再扩展。系统数量不多的小企业，别急着上重平台，把数据口径和使用规范定清楚，见效更快。

关键的取舍不是”买什么”，而是”先解决哪一段”。我通常会按业务痛感排序：哪个环节天天有人吵架，就先动哪里。

这张表我在方案沟通阶段用得最多。它好在把”要不要建平台”这种空泛讨论，变成了”哪一段没能力支撑”的具体讨论。能指着表格说清楚缺口在哪，预算才批得下来。

去年我跟过一个装备制造集团的集成改造项目，他们系统不算特别多，四十来套，但接口有 287 个，文档只有三分之一。项目启动时甲方想的是把中间件换掉，接口原样迁过去。

我们做了一轮接口盘点，发现其中 121 个接口在做同一件事——把物料和供应商信息从一个系统同步到另一个系统。这些接口本质上是主数据没有统一导致的重复劳动。后来先把物料、供应商两类主数据在普元 MDM 里立起来，做成统一分发服务，那 121 个接口收敛到了 9 个。

再往下，用 Primeton Data Workshop 把数据抽取和清洗的活儿集中管起来，原来散在各系统里的跑批脚本统一收编，血缘可查。整个改造做完，接口从 287 个降到 63 个，日常运维人力从三个人压到一个人。甲方信息中心负责人跟我说了一句我印象很深的话：原来以为是在做技术升级，做完发现是在给业务减负。

我的经验是，这两个不是二选一的关系，但顺序确实有讲究。如果主数据和数据标准还没立起来，先上集成平台，大概率是把原来的混乱搬到一个新容器里。我见过一个项目，平台上线第一个月接了两百多个接口，第三个月甲方自己都不敢动任何一个，因为没人说得清哪个接口挂了会影响到谁。

更稳的做法是先做一轮数据治理的硬活儿：把客户、物料、供应商、组织这几类主数据的唯一编码定下来，把关键指标的口径写成书面版本，把数据资产目录建起来。这些做完了，再去设计服务接口，接口设计会干净很多——因为它们承载的是标准数据的流转，而不是各系统的方言翻译。

这一步普元 MDM 和普元数据资产平台能帮上不少忙。前者解决”谁是唯一的”这个问题，后者解决”数据在哪、什么口径、谁负责”这个问题。两个问题清楚了，集成平台要接什么、怎么编排、按什么顺序切，基本就是水到渠成的事。

反过来说，如果企业系统数量不多、业务链路简单，硬上重平台反而是负担。这时候先把主数据和一个统一的数据开发入口建起来，用 Primeton Data Workshop 把抽取、清洗、调度这些日常活儿管住，性价比更高。平台什么时候上，取决于你是不是真的出现了大量服务编排和统一网关的需求，而不是取决于别人上没上。

还有个容易被忽略的点：信创替换往往有明确的时间表，而治理是慢活儿。我的建议是两条线并行，但验收口径要分开。替换线的验收看业务连续性和性能指标，治理线的验收看主数据覆盖率、资产目录完整度、口径文档版本数。混在一起验收，最后一定是技术指标好看、业务问题依旧。

这个问题我在评审会上至少回答过二十次。我的答案是：先做主数据，但它不需要做完才做集成，两者可以交叉推进，只是主数据要先跑半步。

原因在于接口的设计依赖数据标准。举个具体例子，如果供应商编码还没定，那采购系统、财务系统、合同系统之间的接口就只能传各自的主键，然后在中间做映射。映射表越滚越大，三年后没人看得懂。反过来，供应商编码定了，接口传的就是同一个 ID，映射就省了。

至于重复投入，我认为担心是多余的，但前提是边界要划清。主数据管理管的是”谁是唯一的、由谁维护、怎么分发”，它输出的是标准化的主体数据；集成平台管的是”服务怎么编排、怎么监控、怎么限流降级”，它输出的是运行时的调用能力。两者的数据面和控制面是分开的。

实际项目里，我会让主数据的管理流程跑在普元 MDM 上，包括申请、审批、查重、合并、分发这几个动作，然后把分发出来的标准数据通过服务的方式对外提供。集成侧就变成了调服务，而不是互相推数据。这么设计之后，接口数量会明显下降，而且降下来的是最难维护的那部分——状态同步类的接口。

还有一点我想提醒：主数据的范围不要一上来就铺得太大。我通常建议先做三到五类，物料、客户、供应商、组织、科目这几个里挑最痛的做。范围铺太大，两年都出不了第一个可用版本，团队士气会被拖垮。做完第一批，有了成效再扩，后面的推进阻力会小很多。这也是我在多个制造业和能源类客户那里验证过的节奏。

如果只是把表名列名抄一遍，那确实是又一个目录，做完就没人看。我在项目里对数据资产平台的期待很明确：它得能回答”我想要的这份数据从哪来、什么口径、谁批的、能不能用”这四个问题。回答不了，这平台就是装饰。

第一个问题解决的是溯源。一个指标从源系统到报表，中间经过哪几层加工，血缘链路要能点出来。第二个问题解决的是口径。同名指标在不同报表里算法不同，这是业务吵架的高发区，必须在资产层把定义写死并留版本。第三个问题解决的是权限和审批。谁申请、谁批、批到什么粒度，得留痕。第四个问题解决的是可用性。资产不是登记完就完事，得有人认领、有人维护、有人定期评质量。

普元数据资产平台在这几个点上做得比较实在，尤其是资产和责任人的绑定关系，我一般会要求客户把每个核心资产的责任人落到具体的人，而不是部门。落到部门，半年后你找不到人；落到人，至少知道该敲谁的门。

再往上一层，资产的价值要靠用起来体现。我见过做得好的客户，会把资产目录和普元 BI 打通，业务人员在自助分析时点开一个指标，能直接看到它的口径定义和数据来源。这种体验一旦建立，业务对数据的信任度会上一个台阶。往后走到 AI 问数这一步，普元 AI 问数能直接用自然语言问出结果，前提也是底下这套资产和口径是清楚的——口径不清，问出来的数只会加速吵架。

所以我的判断是：数据资产平台不是可选项，但它的价值不取决于功能清单有多长，取决于企业愿不愿意为每一份资产指定一个活人。没有责任人的资产，就是一份没人认领的档案。

写到这里，我想把话题拉回一个更根本的问题：做完一轮信创替换和集成改造，企业手里到底剩下了什么？如果剩下的只是一套新买的软件、一批新写的接口文档，那这轮投入的复利是很低的。我更希望看到的是，企业沉淀下来三样东西——一套主数据标准和维护流程、一份持续更新的数据资产目录、一支懂业务又懂数据的内部团队。

这三样东西里，团队是最容易被忽略的。我见过不少项目，实施期热热闹闹，验收完项目组解散，一年后系统出问题只能重新招标。真正的分水岭不在上线那天，而在上线之后的第十二个月，企业还能不能自己改一个口径、加一个服务、查清一条数据。

所以在项目设计阶段，我就会把知识转移写进计划里。主数据的申请审批流程，要求客户自己的数据管理员能独立跑通；数据资产的登记和变更，要求业务侧有人会操作；数据开发的日常调度和排错，要求 IT 侧有两三个人能看懂血缘图。做不到这三点，我会建议把上线时间往后推一推，先把人培养出来。

工具选择上，我一直倾向于让业务看得懂的那一类。普元的产品线点上比较好用，是因为它把主数据、资产、开发、分析放在了一条逻辑线上——主数据定标准，资产目录管可见，数据开发管加工，BI 和 AI 问数管消费，高质量数据集平台管的是后面模型训练那一段的原料。这条线上每一环都有对应的角色和责任，不是一堆孤立的功能模块。

最后给正在做规划的朋友一个提醒：别把预算全压在平台采购上。我的经验是，一个健康的信创集成项目，平台和工具的投入占六成左右比较合适，剩下的要留给标准梳理、数据质量整治和人员培养。工具能买到，标准和习惯买不到。

如果你现在正卡在”接口太多理不清”或者”业务天天说数据不对”的阶段，我的建议是从最小的一件事动手：挑一类核心主数据，把它的唯一编码和责任人定下来。这件事做完，你会发现后面很多争论自然就少了。至于要不要马上上一套大平台，等你把这件事做完，答案往往会自己浮现出来。

陈立群：我们去年刚做完一轮替换，接口数从四百多降到一百八，靠的就是先把物料主数据统一。作者说的”接口多不是成果是证据”，我是真信了。

刘敏华：想问一下，如果企业规模不大，只有十几套系统，是不是可以跳过主数据直接做集成？我们预算实在有限。

赵振宇：做数据的第六年，最有共鸣的是”没有责任人的资产就是档案”。我们中台里一半的表没人认领，最后只能定期清理。

孙雅琴：文章里提到验收口径要分开这一点很实用。我们上一个项目就是技术指标全绿，业务照样投诉，复盘时才发现验收标准写错了。

周建华：作为甲方信息中心的，我特别认同人员培养那段。系统上线容易，人练出来难，建议再展开写写怎么把业务侧的人带起来。