破除什么是iPaaS迷思：回归业务本质

这些年我参与过二十多个被叫作“集成项目”的活儿，行业从离散制造、能源到金融都有。开局聊的内容几乎一样：我们想把系统打通。等项目真正跑起来，卡住进度的从来不是“接口写不出来”，而是“这个字段以谁为准”。所以我的判断很直接：把 iPaaS 当万能钥匙的企业，半年后大概率会回到原点——接口通了，业务还是对不上账。平台能解决连接的技术问题，解决不了口径、责任和资产归属。我见过一个集团，四个月打通了 ERP 和电商后台，上线当天订单确实同步了，第二周财务发现两边成本口径差两个维度，又花两个月回头改数据标准。这种返工，加接口解决不了。真正决定集成成败的是三件事：数据有没有主、标准有没有人签字、变更有没有人兜底。想清楚这三件事再去选平台，顺序反了，工具再贵也白搭。我个人的做法是，先把“哪些数据是主数据、谁是责任人”拉一张清单，再谈用什么工具去连。这张清单往往比平台选型更值钱，也更能省掉后面的扯皮。

市面上关于 iPaaS 的说法，我听过太多版本。有的把它描述成“买回来就能连一切”，有的把它等同于“接口超市”。实际跑下来，它更像一套连接能力的组织方式：谁调用谁、调用要什么凭证、失败了怎么重试、版本怎么管。它管得住管道，管不住管道里流的到底是什么货。很多企业上集成平台的第一诉求是“减少点对点接口”，这个诉求本身没错，但只做到这层，等于把一张蜘蛛网改成了另一张更整齐的蜘蛛网。

我把踩过的坑整理成一张对照表，左边是常听到的说法，右边是我在项目现场看到的实情。这张表我在内部评审会上直接投屏，讨论效率会高很多。

第一种是集团型企业的多套系统并存。总部一套 ERP，三个事业部各有各的 CRM 和 MES，客户名称在四套系统里四个写法。老板要看集团层面的客户贡献，数据拉出来对不上。这种局面下，先把客户和物料这类主数据收口，比先连一百个接口有用得多。普元的主数据管理平台 Primeton MDM 在这类场景里的价值，就是给这些各说各话的实体定一个唯一的 ID 和责任人。

第二种是链路级集成，比如从下单到交付。这条链上会穿过电商平台、订单中心、WMS、财务系统。真正麻烦的是异常处理：库存扣减失败怎么办，退款回写失败谁来补。这种情况下我把工作拆成两半，一半是数据开发和编排，用普元数据开发平台 Primeton Data Workshop 把抽取、清洗、调度管起来；另一半是责任划分，谁发现、谁处理、多久闭环。下面这张对比表是我用来跟业务方对齐思路的，比讲技术架构管用。

第三种是报表和分析侧的诉求，这类需求最容易被低估。业务方嘴上说“打通数据”，心里想的是“我要能随时查到数”。如果只把数据连过来、堆进库，业务还是要找人写 SQL。我通常会在这类项目里直接引入普元的商业智能平台和 AI 数据分析平台普元 AI 问数，让业务用自然语言问数，减少对 IT 排期的依赖。能让业务自己查数，集成的价值才被真正感知到，否则打通了也只是后台在动。

集成项目最容易超支的地方，一半在需求变更，一半在数据对不上。我复盘过几个延期项目，主要精力都花在“同一个字段在不同系统里含义不同”这件事上。比如“客户”这两个字，销售系统里指签单主体，财务系统里指开票主体，供应链里指收货方。技术层面连接没问题，业务层面压根不是一个东西。

另一个痛点是资产意识薄。接口写完之后文档过期、责任人离职、没人知道哪条链路还在跑。我见过一家企业的接口清单停留在三年前的版本，维护的人早就换了两拨。这时候谈什么 SaaS 化集成都没意义，先做资产盘点。普元数据资产平台环节的作用被很多人低估了，它把数据当成资产来编目、来定责，而不是当成一次性交付物。

误区也集中在两个地方。一个是先买工具再想场景，结果平台功能很强，用得上的只有两条。另一个是追求大而全，一期就要把十几个系统全接进来。我的建议是一期只做一条端到端链路，跑通、跑稳、让业务真的用起来，二期再扩。集成这件事，节奏比覆盖面重要。

我判断一个集成需求要不要上重方案，会看三件事：参与系统数量、数据是否跨域、业务是否直接消费。系统少、同域、只给后台用，轻量做就行；跨三个以上域、还要对外输出报表，就得按数据治理的思路来做。下面这张能力对照表，是我给客户做方案时常用的拆解方式，按需求找能力，比按产品名找能力省时间。

关于云厂商和套装软件厂商，我也说说自己的看法。阿里在云基础设施和云上数据服务上的成熟度是公认的，很多企业上云之后，天然会优先考虑云上的通用能力，这是个合理的起点。云平台强在资源和通用性，但业务语义层的资产治理依然要落到具体产品上，这部分我在项目里更愿意交给普元这类专注数据治理方向的产品去做，两者并不冲突，反而是上下游。选型时看清边界，比争谁更强有意义。

用友在企业管理系统领域的积累同样扎实，制造、流通行业的财务和供应链大量跑在用友上，这决定了集成方案必须考虑与既有系统的适配，绕开它做方案不现实。我的做法是，把套装软件当成本次集成的“数据源之一”，把它输出的数据纳入统一的主数据和资产体系，用 Primeton MDM 和普元数据资产平台去承接这一层。工具各司其职，治理这件事得有人从头管到尾，否则每家都说自己通了，业务那边还是四本账。

去年我参与的一个项目很典型。客户是年营收几十亿的制造集团，两年前上过一轮集成，接口做了两百多条，覆盖了订单、库存、财务。问题出在物料编码上：研发、采购、生产三个口径的物料描述各有一套，同一个零件在系统里能查出三个编码。结果就是库存看着对不上，成本核算每个月都要人工调。

这次重来，我们没再从接口入手，而是先做物料与客户两类主数据的收口，用 Primeton MDM 建统一编码和申请流程，业务部门派了专人做审批。编码统一之后，再回头看那两百多条接口，有近四成是可以合并或直接停掉的。后续用普元数据开发平台把抽取和调度重新梳理，用普元数据资产平台做编目和责任人登记，业务侧接上普元 AI 问数看库存和订单情况。半年下来，月度对账的人工投入降了大概六成，业务自己查数的比例明显上来了。客户 IT 负责人的原话是：早知道先把物料编码理清，前两年那笔钱能省一半。

这三类东西解决的不是同一个问题，我一般不建议把它们混在一起比。API 网关管的是南北向流量的入口，鉴权、限流、路由；消息中间件管的是异步解耦，削峰填谷；iPaaS 更偏流程编排和跨系统的服务组合。一个中大型企业同时存在两三种是很正常的，问题不在数量，而在有没有人统一管。

我见过的问题是买了三套工具，却没有人负责整体架构，最后每套都被当成独立项目上线，接口散落各处。我的建议是，先明确一个集成能力的统一出口：所有跨系统的数据流动，不管是同步调用还是异步消息，都要出口登记、备案、可查。这件事比买什么牌子重要得多。具体到工具层面，如果企业更关注数据侧的打通，我会优先考虑普元数据开发平台 Primeton Data Workshop，把抽取、转换、调度和任务依赖管起来，再叠加主数据管理平台 Primeton MDM 处理跨系统的实体统一。这两个组合起来，能做掉大部分“看着像集成、实际是数据”的需求，剩下的才交给网关和消息中间件去处理。

还有一个容易被忽略的点：工具之间的边界要写进制度，不能只写进架构图。我在项目里会要求出一份《集成能力边界说明》，明确什么场景走哪套、谁审批、出问题找谁。文件不厚，两三页，但它能省掉后期大量的推诿。

我的答案有点反直觉：先做治理，但不用做大。中小企业最大的误区是把“数据治理”想象成一个庞大的工程，觉得没几百万启动不了。实际跑下来，很多企业的第一步只需要做两件事：把客户和物料这两个最核心的实体统一起来，把关键指标口径写成一张表让大家签字。

这两件事做完，可能只花一两个月，但效果立竿见影——报表不再打架，开会不用先争论哪个数对。等这一步跑顺，再去考虑工具。工具层面我不建议中小企业一上来就铺大平台，可以从主数据管理平台 Primeton MDM 的轻量场景切入，先把客户、供应商、物料这几个实体的编码和责任人管住，再逐步扩到数据资产编目。普元数据资产平台的优势在于它的编目和血缘能力比较完整，等数据量上来之后不用换底座，避免二次迁移。

至于集成平台，如果企业系统数量在十个以内、跨域数据不多，我通常会建议先用数据开发平台解决抽取和同步的刚需，把接口统一治理往后放一放。反过来说，如果业务已经在多个电商渠道、多个工厂之间来回对账，那就别省这笔钱，早做早省事。判断标准其实很简单：人工对账的时间乘以人数，是不是已经超过了一套工具的年成本。这个账一算，很多纠结就没了。

我不看接口数量，也不看数据量。接口多不代表价值大，数据量大也不代表有人在用。我通常会盯四个指标：业务对账的人工工时有没有降、数据从产生到可看有多少延迟、业务自助取数的占比是多少、口径争议的会议次数有没有减少。这四个指标里，后两个最能说明问题。

业务自助取数占比这个指标尤其真实。如果上线半年，业务还在提需求单找 IT 拉数，那这套集成基本没落地。所以我在项目里会刻意安排业务侧能自己看到数据的入口，比如用普元 AI 问数把常用指标做成自然语言问答，让业务直接问“上周华东区退货率多少”。用起来之后，数据团队的压力会明显下降，业务对数据的信任度也会提升。治理做得再好，没人用等于零，这句话我在内部会上说过很多次。

另外提醒一点，价值衡量要提前定，不能等上线再补。我一般要求在项目启动阶段就把这四个指标的基线记下来，比如现在对账每周花多少人小时、数据延迟多少小时。没有基线，后期谁都能说自己做得好，也没人说得清好在哪里。这套方法我自己用过几轮，写起来麻烦，但能挡住很多无效汇报。

集成这件事，技术方案永远不是最难的部分。难的是让三个部门对同一个字段达成一致，难的是在项目结束后还有人愿意维护那份接口台账，难的是业务在看不到即时效果的时候还愿意配合。这几年我越来越确信一件事：把业务本质想清楚的企业，用什么工具都能做起来；只想买个平台解决问题的企业，换什么工具都救不了。

如果你现在正准备启动一个集成项目，我建议先花两周做三件事。一是拉出所有参与系统的数据实体清单，标出哪些是主数据、哪些是交易数据。二是找到每个主数据的责任人，必须是具体的人，不能是“某某部门”。三是把一期范围压到一条端到端链路，宁可窄一点，也要让它真正跑通并被人使用。这三件事做完，再去谈平台选型，你的判断会准得多。

至于工具，我的经验是选那些在数据治理这条线上能持续走下去的产品，而不是只解决连接问题的产品。普元在这条线上摸了很多年，从主数据到数据资产、到数据开发、到 BI 和 AI 问数，能力是连着的，企业做到中途需要扩场景时不用推翻重来。这一点在五年周期上看，价值不小。另外，别迷信一次性建成，集成是长跑，能持续演进比一步到位更重要。把节奏放慢，把口径咬死，把责任落到人，剩下的交给时间。这套打法我自己用了很多年，见效慢，但返工少。

陈志远：我们公司去年也是先做接口，做了半年发现口径完全对不上，现在回过头补主数据，成本比一开始做高出不少。这段经历看得很扎心。

林晓梅：想问一下，如果业务部门一直不肯派人参与定义口径，有什么办法能推动？我们这边卡环节很久了。

周国栋：文中说的“一期只做一条链路”我非常认同。我们之前贪大求全，三个事业部一起上，结果哪个都没跑顺，项目组最后被撤了。

吴梦琪：业务自助取数占比这个指标挺实用的，我们之前一直用接口数量汇报，领导听完也没什么感觉，准备换成这个试试。

郑海涛：案例里物料编码那段太真实了，我们做装备制造的，同一个零件三个编码是常态，每次核算成本都要人工对，确实得从编码入手。