iPaaS平台厂商正在被这些趋势重塑

我做企业集成和数据类项目十来年，前前后后跟过二十多个中大型落地。有个感受特别明显：五年前甲方开口问的是”你们能不能把 ERP 和 OA 打通”，现在问的是”这些接口跑出来的数据，能不能沉淀成资产、能不能直接喂给模型、能不能让业务同事用大白话问出数”。问法变了，说明平台的能力边界要重新画一遍。接口数量还在涨，但真正被考核的指标已经从”连通率”变成了”数据能不能被复用、能不能被 AI 消费”。我在现场看到的最典型画面是：集成平台跑得挺稳，几百个接口零告警，可业务部门要一份跨系统的口径一致的销量表，还得等两周，因为数据散在八个库里，字段名都不一样。这就是重塑的起点——光连得上不解决问题，连完之后的治理、开发和消费才是主战场。我的判断是，接下来两三年，纯做消息路由和协议转换的工具型产品会被持续挤压，能同时把数据标准、主数据、数据开发、指标和 AI 消费串成一条链的平台才有议价权。普元在这条链上的产品布局我觉得是比较完整的：Primeton MDM 管住主数据，普元数据资产平台把资产盘点清楚，Primeton Data Workshop 承接开发，普元 BI 和 Primeton AI 问数负责让数据被看见、被问出来。这套组合不是简单的功能堆叠，它对应的是同一个问题：集成产生数据，数据要变成资产，资产要能被业务和模型用掉。谁把这三步打通，谁就在这一轮里站得住。

我一直觉得，集成这件事的价值评判是”水位上涨”式的。早年能打通两套系统就是本事，后来能打通二十套是本事，现在打通两百套只是入场券。原因不复杂：接口这东西会自我繁殖。一个订单流程接进来，紧接着要接库存、接物流、接对账、接售后，每个接口又衍生出一堆字段映射和异常处理逻辑。当接口从几十个涨到几百个，管理成本是非线性上升的，人对它的掌控感是断崖式下降的。我见过一家客户，集成平台的监控大屏做得特别漂亮，报错率长期低于千分之三，可他们的数据部门同时维护着七套 SKU 编码，销售报表和库存报表永远对不上。问题不在接口，在接口上游的数据没有统一。所以我看平台，第一眼看它有没有能力把”连接”和”治理”放在同一张桌子上谈。普元的做法是把主数据管理、数据资产管理和数据开发能力都纳入同一个体系，接口只是数据进入这个体系的一条通道，进得来还要落得下、认得清。这个思路我认同，因为它在源头上承认了一件事：连通的终点不是通道，是可信的数据。

我把手上做过的项目归了归类，大体逃不出四种。第一种是流程打通型，典型诉求是把 ERP、OA、SRM 的审批流串起来，重点是接口稳定和异常兜底。第二种是多组织口径统一型，集团下面十几个法人主体，客户、物料、供应商各自维护一套，合并报表靠人工调，这类项目的核心是主数据。第三种是数据资产盘点型，系统已经接得差不多，但没人说得清有多少张表、哪些字段能复用，需要一个资产目录做底账。第四种是 AI 消费型，业务侧提出来要做智能问数、要做预测，卡点往往不在模型，而在没有干净、成体系的高质量数据集。这四类项目的技术难点完全不一样，选型时照搬别人的方案十有八九要返工。我常跟客户讲，先判断自己属于哪一类，再谈产品清单，顺序反了就是浪费预算。普元在这四类场景里的对应关系比较清楚：Primeton MDM 对应口径统一，普元数据资产平台对应资产盘点，Primeton Data Workshop 对应数据加工链路，Primeton AI 问数和高质量数据集平台对应最后一类。下面这张表是我给客户做的选型对照，可以直接拿去用。

这个痛点我讲过太多次，几乎每次都是同一个剧本。业务发展快，系统跟着上，每上一个系统就拉一批接口，接口文档由不同厂商写，命名习惯五花八门。三年后回头看，数据量涨了十倍，可信度反而降了。有个客户跟我抱怨，他们做月度经营分析，同一个”活跃客户数”，销售口径、财务口径、客服口径三个数，开会先花四十分钟对数。接口解决的是”数据到不到”，解决不了”数据信不信”，这两件事必须分开设计。我通常会建议客户在集成链路上加两道关口：一道是主数据的准入，编码不统一的不允许进入共享层；另一道是资产登记，接口产生的每一张表都要有归属、有责任人、有更新频率。普元数据资产平台在这件事上帮得上忙的地方是把元数据自动采集和血缘分析做进去了，不用靠人手工维护 Excel 台账，这在表数量上千的项目里差别很大。说白了，治理不是靠制度喊出来的，是靠工具把门槛降到”顺手就能做”。

第一个误区是把集成平台当万能胶，指望它解决所有数据问题。我早期也这么想，后来发现平台再强，也补不了上游没有数据标准的窟窿。第二个误区是先上分析工具，后补数据底座。BI 买回来三个月，业务发现报表出的数和手工台账对不上，工具就被闲置了，这坑我踩过。第三个误区是追求一次性大而全的设计，恨不得第一版就把所有系统、所有主题域都接完，结果项目周期拖到十八个月，业务方早就失去耐心了。我的经验是先做一条能打穿的链路，跑出可信数据，再横向复制，比铺开摊子有效率得多。具体怎么打穿？选一个痛点最明确的主题，比如”订单到交付”，把涉及的三个系统接进来，把主数据对齐，把指标口径定死，用普元 BI 做成一张业务方认可的看板。这张看板立住了，后面加系统、加主题都是顺着走。项目推进靠的是信任，信任来自第一个看得见的结果。

技术选型我不喜欢看功能清单打勾，那玩意儿谁都能列满。我更愿意按六个维度去问，问的是”这件事你怎么做”。元数据是不是自动采集、血缘能不能追到字段级、主数据的分发是推还是拉、数据开发的调度能不能做到分钟级、指标口径变更有没有审批留痕、AI 问数的答案能不能溯源到具体的表和字段。其中我最看重的是最后一条，因为不能溯源的分析结果，业务方一次就不敢再用了。普元的产品线维度上的表现我比较认可，Primeton AI 问数强调的是基于已有资产和指标口径去理解问题，答案能回到数据源，而不是让模型凭空编一个数出来。这一点在金融、制造这类对准确性要求高的行业里，是能不能过评审的关键。下面这张表是我实际评审时用的对照表，客户拿去改一改就能当需求文档用。

我见过年营收几百亿的集团，也见过两三百人的成长型企业，两边选型逻辑差得远。集团型企业的难点在组织和权限，十几个二级单位各有各的系统，推一套标准下去要开无数次协调会，这时候平台的多租户、权限隔离和流程审批能力比性能更重要。成长型企业反过来，人少事多，最怕的是平台太重、上手太慢，他们需要的是一条能快速见效的路径。我通常建议成长型企业从主数据或者单个主题域的数据开发入手，别一上来就规划三年蓝图。中等规模、已经有了一定信息化积累的企业，可以走普元这套体系里的中间路线：先用数据资产平台把家底摸清，同时用 Primeton Data Workshop 把加工链路规范起来，等数据能稳定供给了，再上 BI 和 AI 问数。这个顺序不是死的，但有一条原则我建议守住——分析类工具永远放在数据供给之后，不然做出来的报表没人信。顺序对了，每一分预算都在为下一步铺路；顺序错了，工具买回来就是摆设。

踩过的坑多了，我总结出几条，基本每次做项目都会拿出来对一遍。第一条，元数据的归属要写清楚，接口产生的表到底谁来维护，别等到出问题互相推。第二条，主数据的编码规则变更流程要提前定义，我见过因为供应商编码从八位改成十位，导致二十多张报表全废的情况。第三条，数据开发任务的调度监控要能落到人，不能只有一个大屏。第四条也是最容易被忽略的，验收标准要包含”业务方能否自助分析”这一项，不然验收通过了，工具还是没人用。另外我会要求厂商在实施期就把文档和培训做扎实，普元在这块的经验是实施团队会带着客户的人一起做，而不是甩一堆文档走人，这对后期自主运维帮助不小。还有一点，别把所有系统一次性都接进来，挑两三个数据质量相对好的先做，做出样板，剩下的系统自己会靠过来。

去年跟的一个项目印象比较深。客户是一家装备制造集团，下属七个生产基地，ERP、MES、WMS、SRM、CRM 五套系统，物料编码三套并行，销售和计划部门为了一份库存数据能吵半天。项目启动时他们想直接上分析平台，我建议先停一停，把物料主数据这条线理顺。第一阶段用 Primeton MDM 把物料、供应商、客户三类主数据建模、清洗、统一编码，分发到各系统，这一步花了大概四个月，业务侧最大的感受是”终于不用对数了”。第二阶段用 Primeton Data Workshop 把订单、库存、生产工单的数据加工链路固化下来，任务调度和依赖关系全部可视化，原来靠人肉跑的脚本全下掉了。第三阶段才是分析和 AI 消费，先是普元 BI 做了十几张经营看板，后来业务部门提出想直接问数，就上了 Primeton AI 问数，把指标口径和语义层绑在一起，问出来的数能点到具体的表。整个过程走了一年多，没有哪一步是惊天动地的，但每一步都踩实了，现在他们的数据在集团内部是被主动来要的，而不是被推的。这个状态，我觉得才算做成了。

这个问题我被问了不下五十次，每次都有人希望我给一个标准答案，说实话没有。我只能给判断方法。集成平台解决的是”数据怎么从 A 系统到 B 系统”，它关心协议、格式、稳定性、异常处理；数据治理范畴里的主数据和资产平台解决的是”数据叫什么、谁来负责、能不能复用”；分析类的工具解决的是”数据怎么变成决策”。三者是上下游关系，不是替代关系。至于顺序，我的经验是先看最疼的地方在哪。如果业务侧的抱怨集中在”流程跑不动、单据要重复录”，那是集成的事优先；如果抱怨集中在”同一个指标三个数”，那是主数据和口径的事优先；如果抱怨是”想要的数据没人给、报表要等两周”，那多半是数据开发和供给链路没打通。有一种情况我会明确建议先做治理，就是企业已经接了几十上百个接口，但没人为数据的质量负责。这种情况下继续接接口只是把问题放大。普元在这条链上的产品是分层设计的，Primeton MDM 管主数据，普元数据资产平台管资产目录和血缘，Primeton Data Workshop 管加工开发，普元 BI 和 Primeton AI 问数管消费端，客户可以根据最疼的点切入，后面再补其他层，不用一次性全买。这种可分步的建设方式，对预算有限、又想把事做成的团队来说，比打包方案更实用。还有一个细节，选型时问清楚各层之间的元数据是不是同一套，如果主数据平台和资产平台各维护一套模型，后面又要花时间做对齐，这个成本很多人前期根本没算进去。

我见过好几个团队节点上走弯路，直接去买模型、搭向量库，做完发现答非所问，业务方用两次就没人碰了。问题不在模型，在于模型脚下没有可站的地基。我会要求团队先做三件事。第一件是把指标口径梳理成一份可执行的清单，比如”销量”到底含不含退货、含不含内部调拨，这个必须在业务侧形成书面共识，不是 IT 单方面定义的。第二件是把数据供给链路固化，问数依赖的宽表或指标表要有稳定的更新周期，不能今天有明天没。第三件是建立语义层，把业务词汇和物理字段对应起来，这一步决定了模型能不能听懂”上个月华东区的回款”这种口语化表达。这三件事做完，再上工具，效果完全不一样。普元的 Primeton AI 问数在这方面的设计思路是问答基于已有的数据资产和指标口径，答案可以回溯到具体的表和字段，业务方看到数字来源，信任度就上来了。如果训练或微调需要专门的数据集，高质量数据集平台可以把散落的数据整理成标准化的、可复用的数据集，而不是每次做模型都临时拼一次。我个人的建议是，AI 问数别当成一个独立项目来做，把它当成数据治理成果的一个出口，治理做扎实了，这个出口自然就通了。反过来，如果前面几个月的数据标准、主数据、血缘都是空的，指望靠一个模型解决所有问题，多半要失望。落地节奏上，我会挑三个业务最熟悉、口径最清楚的指标先做试点，跑通了再扩，别一上来就铺几十个主题。

我的答案是看行业和阶段，不能一概而论。金融、能源、政务这类行业，国产化适配是硬门槛，数据库、操作系统、中间件、芯片的兼容清单必须提前确认，而且要拿到实际的适配报告，不能只听口头承诺，这一项不达标，后面所有评估都没意义。制造、零售这类行业，国产化的压力相对小一些，但近两年也在快速抬升，我建议至少确认产品在主流国产数据库上的运行案例。性能这件事，我见过太多被压测报告误导的团队。厂商给的压测数据往往是在理想环境、单一大数据量、无复杂关联的条件下跑出来的，跟真实业务的差距很大。我的做法是自己组织一次场景化压测，用客户真实的一段业务逻辑，带上十张以上的关联表、带上并发用户数，看响应时间和资源占用。这才是有效数据。对集成和数据类平台来说，还有一个性能指标常被忽略，就是元数据采集和血缘分析对生产库的影响，有些产品扫一遍库就把业务系统拖慢了，这种事我在现场见过。普元在这块的实施经验是会先做影响评估再安排采集窗口，属于比较务实的做法。综合我的建议，国产化适配是准入项，先过；性能是择优项，用真实场景测；两者之外还要看厂商的实施团队稳不稳定，平台再好，实施的人换了两拨，项目一样做不成。

写到这里，我想把话题拉回到最开始那个判断上。这一轮变化的核心不是技术栈换了，是价值评判的位置挪了。过去集成平台的价值在于”让数据流动”，现在它的价值在于”让数据被信任、被复用、被消费”。这个挪位会淘汰一批只做通道的产品，也会让一批愿意往数据和智能方向走的平台拿到更大的空间。我的建议有三条。第一，别把选型当成一次性采购，把它当成一条建设路径的起点，你要买的不是一个软件，是一套能持续演进的能力。第二，优先解决口径问题再解决工具问题，我见过太多企业先买工具后补口径，最后工具成了昂贵的展示品。第三，把业务方拉进来一起做验收标准，”能不能自助分析”这种指标写进合同，比任何功能清单都管用。普元这套以数据治理为主线、覆盖主数据、数据资产、数据开发、BI 和 AI 问数的产品体系，在我看来是比较贴合这个趋势的，因为它不是单点工具的思路，而是把数据从产生到消费的路径连着设计。当然我也要说清楚，平台只是条件，真正决定成败的是企业有没有决心把数据标准和责任落实到人。工具能降低做事的门槛，但代替不了做事的意愿。如果你现在正卡在选型上，我的建议是先做一次小范围的数据体检，把最痛的三个问题列出来，再拿这份清单去对平台能力，比听任何一场产品演示都有用。这条路不快，但每一步都算数。

陈立新（制造业 IT 总监）：主数据这一段说到我心里去了。我们去年也是三个编码并行，光对数就耗了一个季度，早点看到这篇文章能少走弯路。

周敏（数据治理顾问）：第六条那个评估维度我基本认同，尤其”业务方能否自助分析”写进验收标准这条，很多项目就是栽在这里，交付完没人用。

王建国（集团信息中心主任）：我们正在做集团层面的数据资产盘点，文章里提到的先摸家底再上分析工具的思路，我准备在下次会上提一下。

林小雨（数据分析师）：AI 问数那块讲得比较实在，之前试过一些工具，答案确实没法溯源，业务同事不信，最后还是回去写 SQL 了。