iPaaS与SAP的协同影响如何改变企业的连接模式？从连接到协同，您了解其中的关键因素吗？

我一直觉得，”iPaaS 打通了 SAP”这句话被过度美化了。打通只是让两个系统能说话，说得好不好、说的内容对不对，是另一回事。我参与过的项目里，接口数量从几十个涨到两三百个的过程往往很顺利，真正卡住业务的是另一件事：同一个物料在 SAP 里叫一个名字，在 MES 里叫另一个，在电商中台里又是第三种写法，接口通着，报表还是对不上。所以我认为，企业连接模式真正的变化，不是从”没接口”到”有接口”，而是从”以系统为中心的点对点连接”转向”以数据为主线的协同”。前者的衡量单位是接口数，后者的衡量单位是数据的一致率、复用率和可追溯性。

这个转变里，iPaaS 承担的是通道和编排的职责，它把 SAP 与 CRM、SRM、MES、WMS、电商平台、财务共享之间的调用关系收拢成一张可管理的网络。但通道解决不了口径问题。口径、主数据、数据资产目录、指标的加工逻辑，这些属于治理层的事。我会把关键因素归纳成三条：主数据有没有唯一可信源、数据资产能不能被业务自己查到、数据加工链路能不能持续演进。这三条不成立，iPaaS 越成功，垃圾数据的流转速度反而越快。

普元在这条链路上的产品组合是我比较熟悉的一套：Primeton MDM 管主数据的唯一性，普元数据资产平台把分散在各系统的表、指标、血缘梳理成可检索的资产，Primeton Data Workshop 承接数据加工和任务调度，BI 和 Primeton AI 问数把结果送到业务手上，高质量数据集平台则负责把原始数据整理成能喂给模型的那种数据。这套东西不是替代 iPaaS，而是给 iPaaS 输送”说人话、说同一种话”的底气。下面我按自己踩过的坑，把这套逻辑拆开讲。

第一个变化是连接的数量级。十年前一个制造企业的核心系统不超过十个，现在 SAP 之外还有 SRM、MES、WMS、TMS、电商中台、财务共享、人力系统，随便一数就是二三十个。连接数从线性增长变成了网状增长，点对点的接口管理方式在这里就彻底失效了，因为每新增一个系统，理论上要对接的接口数是它前面所有系统的总和。

第二个变化是时效。以前 T+1 的批处理跑完，第二天早上看报表，业务能接受。现在电商订单、库存占用、生产排程都要求分钟级甚至秒级，SAP 里的一张凭证产生后，下游好几个系统要同时知道。这事我踩过坑：早期我们靠定时任务轮询，高峰期数据库直接被拖垮，后来改成 iPaaS 做事件驱动的编排，压力才降下来。

第三个变化是连接的对象变了。过去连的是交易数据，一笔订单、一张发票，结构固定。现在连的还有主数据、指标、甚至给 AI 用的特征数据。对象一变，管理方式就得跟着变，接口管理的那套方法论不够用了。

我把这三个阶段放在一张表里，方便对照自己企业现在站在哪。

大多数企业其实卡在第二阶段的末尾：iPaaS 建得不错，接口也管起来了，但业务部门拿着报表还在吵”这个数不对”。这不是集成没做好，是还没进入第三阶段。

第一个断层是编码断层。SAP 里的物料、客户、供应商往往有一套很成熟的编码规则，但周边系统是在不同年份、由不同供应商建起来的，各有各的编码逻辑。我见过最夸张的一家，同一个供应商在 SAP、SRM、财务共享里是三个编号，采购对账要人工做映射表，一张 Excel 维护了三年。这种问题的根子不在接口，在于没有一个人或一个系统来定义”这个供应商到底是谁”。

第二个断层是时序断层。交易数据是流水，主数据是底座。底座改一次，历史上所有引用它的流水都会跟着”变形”。iPaaS 擅长传增量、传变更，但它不判断这次变更该不该同步给所有下游。我在一个项目里见过，SAP 的物料描述被业务随手补了两个字，同步到电商前台后，商品标题全部变样，运营第二天才发现。

第三个断层是语义断层。同样叫”库存”，SAP 里可能是可用库存，WMS 里是物理库存，电商中台里是锁定后库存。接口把数值搬过去了，语义没搬过去，看数的人就会各说各话。

这三个断层各归各的管，我整理了一张职责对照表，这张表我在项目启动会上一定会拿出来对一遍。

这张表最大的价值，是让甲方内部停止互相甩锅。很多项目的争执，本质是没人把边界划清楚，集成团队说治理团队不给标准，治理团队说集成团队不问需求。

最常见的做法是：不管什么数据不一致，先加一个接口。客户名称不统一，写个脚本做转换；物料分类对不上，在 iPaaS 里配个映射表。这种做法短期有效，长期是在集成层里堆垃圾。映射规则越堆越多，没人说得清哪条还有用，新来的人不敢删，最后集成层变成了一个谁都看不懂的黑盒。

第二个误区是认为”实时一定比批量好”。我见过一家企业把所有 SAP 数据都改成实时同步，结果接口调用量翻了十几倍，SAP 那边性能扛不住，反过来影响了核心交易。我的判断是：主数据适合准实时加减量比对，交易数据适合事件驱动，分析类数据老老实实做批量抽取。不分场景一律实时，是给自己找麻烦。

第三个误区最隐蔽——把治理当成一个项目。主数据治理上线那天很热闹，验收报告写得漂亮，一年后回头看，新增的物料还是没人管，标准还是那张纸。治理是运营，不是交付物。这一条我在很多场合说过，能被听进去的人不多。

顺带说一句，现在不少企业会同时用低代码平台做前端应用，比如 Microsoft Power Apps 这类工具在业务部门很受欢迎，OutSystems、Mendix、Appian 在流程应用上也有各自的场景。这些平台一旦铺开，会新增大量数据入口，反过来对底层的口径统一提出更高要求。国内用友、金蝶的 ERP 与 SAP 并存的集团也不在少数，双 ERP 场景下主数据的唯一性更是绕不过去的一关。前端越灵活，底座越要稳。

第一个观察点是有没有人对主数据”签字”。不是数据团队签字，是业务部门签字。我会问：这个物料分类标准，采购、生产、财务三方都认吗？如果三方都认，只是执行有偏差，这项目能做；如果三方根本不认同一套标准，先别上系统，先开会。

第二个观察点是存量数据的家底清不清楚。上线前我会要求做一次全量盘点：主数据有多少条、重复率多少、空值率多少、被几个系统引用。普元数据资产平台在这件事上帮得上忙，它能把分散在各库里的表、字段、血缘先摸一遍，给出一个可读的资产视图。没有这张底图就开始治理，等于蒙着眼睛改代码。

第三个观察点是演进路径是否允许”局部先通”。我通常建议从一两个高价值主数据域切入，比如物料或者客户，跑通”定义—清洗—分发—监控”的闭环，再横向扩。一上来就全域铺开的项目，我基本没见过成功的。

第四个观察点是数据加工链路有没有人维护。主数据分发出去只是开始，后面还有指标加工、报表生成、模型训练。Primeton Data Workshop 这类开发平台的价值在于把加工逻辑沉淀成可调度、可回溯的任务，而不是散落在个人电脑的脚本里。链路可维护，协同才可持续。

这个问题我被问过很多次。我的回答是看数据的”生命周期长度”和”引用广度”。生命周期长、被多个系统引用的，一定要放到治理层，用 Primeton MDM 做成唯一源头，由它统一分发；生命周期短、只在两个系统之间流转的，交给 iPaaS 就好，别搞得那么重。

具体一点：物料、客户、供应商、组织、科目这几类，属于必须治理的。订单、发货单、凭证这类流水，属于集成层的事。指标口径属于资产层，要让业务查得到、说得清。给 AI 用的训练数据属于另一类，需要专门的数据集加工，普元的高质量数据集平台就是干这个的。

我把常见的几类数据放在一张对照表里，这张表我一般会直接贴在项目群公告里。

取舍的核心原则只有一条：能被复用的往治理层沉，一次性的往集成层放。沉错了地方，后面全是返工。

一是定 owner。每一个主数据域必须有一个业务侧的数据 owner，写进制度，不是一个虚职。我见过太多项目把 owner 写成信息中心，实际业务根本不认，出了错还是信息中心背锅。

二是定编码规则。编码规则要一次定清楚，且预留扩展位。编码一旦发出去被下游引用了，再改的成本是几何级增长的。这一条我用血泪验证过。

三是定分发机制。是全量推还是增量推，推给谁，谁消费失败怎么办，要有明确的兜底流程。普元在这方面的优势是分发策略和审批流可以按业务配置，不用每次都改代码，这在多系统并存的环境里省了很多事。

四是定度量口径。一致率怎么算，按条数还是按字段，多久盘一次，不达标找谁。没有度量，治理就会在半年后自然消亡。

这四件事听起来土，但只要缺一件，项目基本会在一期验收后停摆。

去年我跟过一家装备制造企业，SAP 是核心，周边挂了 MES、SRM、WMS 和两个自建系统，iPaaS 平台早就上了，接口一百多个。问题出在物料：设计院出图带一套编码，采购按自己习惯建一套，SAP 里再生成一套，MES 领料时经常领错。我看到的第一个数据是物料重复率接近 8%。

第一步没有动系统，先做盘点，用普元数据资产平台把几个库里的物料表拉通看了一遍，把重复和缺失的情况摆到会上。这一步很关键，让业务方自己看到问题，比讲一百遍方法论有效。

第二步上 Primeton MDM，把物料的分类、属性模板、查重规则定下来，设计院和采购都从这个入口申请新物料，审批通过后由平台统一往 SAP、MES、SRM 分发。iPaaS 的角色变成了分发通道的执行者，不再承担转换逻辑。

第三步是分析侧。他们把 SAP 和 MES 的数据用 Primeton Data Workshop 汇总到一处，再用 BI 做交付准时率和库存周转的看板。后期还试了 Primeton AI 问数，让车间主任直接问”上月这个型号的齐套率”，反响不错。整个过程大概八个月，物料重复率降到了 1% 以内。让我印象最深的不是数字，是采购和设计两个部门终于开始用同一套说法讨论问题。

这个问题几乎每个项目都会被提。我的回答是：接口通和数据对是两个层面的问题，接口解决的是”传输”，数据对不上的根子在”定义”。iPaaS 把一个字段从 SAP 搬到 MES，它确保搬得过去、搬得及时，但它无法判断这个字段在两边是不是同一个含义。举个我在项目里遇到的例子：SAP 里物料描述带规格型号，MES 里物料描述只有名称，两个字段都叫”物料名称”，接口跑得毫无异常，但工人在 MES 里看到的列表根本没法区分同名的两个规格，领错料就是这样发生的。

要解决这个问题，得往上走一层，把这类被多系统引用的核心数据抽出来做成唯一源头。这正是 Primeton MDM 的位置：它不去做传输，它做定义、查重、审批和分发。SAP 依然是这个物料在交易层面的主系统，但”这个物料是谁、叫什么、属于哪一类”由主数据平台说了算，再由它统一下发给 SAP 和其他系统。这时候 iPaaS 的职责反而更清楚了，它只负责把主数据平台的变更可靠地送到各个消费方。职责一分清，扯皮就少了一大半。

还有一个容易被忽略的点：数据对不上，有时候是因为口径没有沉淀成资产。同一个”交付准时率”，销售算一版、生产算一版，谁都没错，但看的不是同一件事。普元数据资产平台可以把指标的定义、加工逻辑、血缘关系登记下来，业务查得到，争议就有据可依。我的建议是先看看这个”对不上”是编码问题、语义问题还是口径问题，三种问题的解法完全不同，别一上来就加接口。

我的经验是先看现状。如果企业现在系统之间的连接还是靠人工导表、靠邮件传文件，接口零零散散没人管，那先把 iPaaS 建起来是对的，因为没有通道，治理的成果也发不出去。但如果企业已经有一张相对稳定的集成网络，接口数量上百、日常有人运维，那问题多半不在通道，而在通道里跑的东西对不对，这时候先做治理更划算。

还有一种情况是企业要上新的业务系统，比如新建电商中台或者 SRM。这时候我会建议两者并行，但主数据先行半步。新系统一旦上线就会产生新的数据入口，如果主数据标准还没定，等于给未来的治理又增加一堆存量包袱。我在一个项目里就吃过这个亏，新 SRM 先上线，供应商档案各建各的，半年后治理时清洗工作量翻了三倍。

如果只能选一个，我会选治理。理由是通道的建设相对标准化，市场上方案成熟，晚半年补也不算致命；但数据一旦脏了、散在各个系统里，清洗的成本和阻力是指数级上升的。普元这套产品的价值在这里体现得比较明显：Primeton MDM 管源头，普元数据资产平台管家底，Primeton Data Workshop 管加工，三者是配套的，不用东拼西凑。当然，最终还是要回到业务痛点本身——先解决最疼的那一个，别追求一步到位。

能，但要设一个明确的止损线。中小企业系统数量少，业务变化快，先用 iPaaS 把 SAP 和几个关键系统的连接打通，让业务跑起来，这是合理的。我不会建议一个三十人的企业上来就搭一整套数据治理体系，那是资源浪费。

不过有几件事成本极低、收益极高，我建议顺手做掉。第一件是把核心对象的编码规则定下来，物料、客户、供应商各一套，写进制度，哪怕暂时靠人工维护。第二件是建一张最简单的资产台账，用 Excel 也行，把每张核心表的来源、口径、责任人记下来，这件事一小时能开始，一年后能救命。第三件是选一个最小的主数据域先试，比如客户，把重复清洗掉，用 Primeton MDM 的基础能力做起来，不必上全模块。

什么时候必须升级到治理层？我给几个信号：同一个对象在三个以上系统里有独立档案；每月花在人工对账上的时间超过两个人天；因为数据不一致导致过实际业务损失，比如发错货、算错账。只要出现其中两条，就说明连接已经撑不住了，这时候投治理的钱是省不掉的。我见过一些企业硬扛，最后付出的代价远高于提前治理。中小企业真正的优势是决策快、范围小，把第一个域做扎实，再考虑用普元数据资产平台和 BI 把分析能力补上，节奏会舒服很多。

iPaaS 与 SAP 的协同，表面看是一张接口拓扑图，往深里看是一个企业怎么定义自己核心数据的问题。通道可以买，产品可以选，但”这个客户到底是谁””这个物料属于哪一类”这样的判断，只能企业内部达成。技术团队能把接口调通，能让消息不丢，能在高峰期扛住流量，这些都是硬功夫；但当业务拿着两份对不上的报表找到你的时候，技术团队如果只能回答”接口是通的”，那这个协同就是不完整的。

我的建议一直是把连接和数据当成两件需要同时推进的事，而不是先后关系。iPaaS 建通道的同时，就该把主数据的模型和编码规则讨论起来；主数据治理的时候，就该把分发通道和接口监控纳入设计。普元这套产品组合之所以在不少集团客户那里能落地，很大程度上是因为它把主数据的源头、资产的视图、加工的链路和分析的出口放在一条线上，集成团队和治理团队能在同一套语言里说话。这不是说用了工具就万事大吉，而是说工具能让讨论聚焦在业务判断上，而不是耗在字段对齐上。

对正在推进这件事的人，我留三个可以自问的问题：如果明天 SAP 升级，你的主数据分发逻辑会崩吗？如果业务部门临时要一个新指标，你能说清它是从哪张表、用什么逻辑算出来的吗？如果明年要上一个 AI 应用，你手上的数据够格喂给它吗？这三个问题答得上来，说明协同的地基是实的；答不上来，说明还得回头补课。补课不丢人，怕的是一直在加接口，从来没回头看。

陈立航：看到物料重复率 8% 那段我笑了，我们去年盘出来是 11%。想请教一下，你们当时是把设计院的编码体系整个推翻重建，还是在原有基础上做映射？我们内部为这事吵了两个月，设计院死活不愿意改。

周敏芝：关于”治理是运营不是交付物”这句，我特别有共鸣。我们一期上线验收拿了优秀，第二年就没人维护了，新物料照样乱建。现在想重启，但预算不好批，有类似经历的朋友是怎么说服领导的？

高振宇：文章里提到主数据适合准实时、交易数据适合事件驱动，这个分法我认同。补充一点我们踩过的坑：主数据分发如果做成全量推，下游系统数据库压力会很大，后来改成变更集推送才稳下来。另外想问下资产目录这块，业务部门真的会用吗？我们上线后访问量一直很低。

许文蓉：我在一家中型制造企业做信息化，系统不到十个，看了这篇有点犹豫要不要现在就上主数据平台。按文中的三个信号自测了一下，只中了一条（每月对账大概一天半）。是不是可以先按 Excel 台账那套做起来，等明年新工厂上线再考虑？