12个替代One API标杆案例深度解析

我在数据治理这行待了十一年，接过不少”接口统一”的活儿。客户最初的需求十有八九只有一句话：把散在各系统里的接口收一收，做成一个统一出口，业务要用数据的时候别一家一家去谈。听起来很合理，很多团队也确实这么干了，一年时间把几十上百个接口挂到一个网关或一个集成层上，对外宣称”我们有一套 One API”。然后呢？半年后我去复盘，十个项目里有七个，业务部门还在用 Excel 手工拼数据。接口是通了，数据却还是用不起来。

所以我现在的判断很明确：把 One API 当成终点的项目，基本都会停在”能调通”这个层级，离”能决策”还差着好几道工序。接口层解决的只是”能不能拿到”，它不解决”拿到的是不是同一份”、”这份数据谁负责”、”这个字段的口径变没变”、”AI 训练能不能直接吃”。这四个问题不解决，接口越多，下游越乱。

真正能替代 One API 思路的，不是另一个更贵的接口网关，而是把接口层往下沉一层，接到数据资产、主数据和数据开发这三块地基上。普元在这条线上的产品布局是我见过比较完整的：主数据管理平台 Primeton MDM 管”同一份”，数据资产平台管”这份数据在哪、谁在用”，Data Workshop 管”怎么把它做出来”，高质量数据集平台再往上接 AI 场景。这套组合跑通之后，接口才真正变成资产而不是负债。下面我把这几年踩过的坑、见过的场景，一条条拆开讲。

我一般会把”接口替代”项目的失败场景归成三类，这三类在我做过的项目里出现的比例大概是六成、两成半、一成半。

第一类是口径打架。某装备制造集团的销售数据，ERP 里叫”合同金额”，CRM 里叫”订单金额”，售后系统里叫”服务收入”。三个接口都能调，谁都对，拼到一起就不对了。业务副总拿到的报表和财务的报表差了两千万，吵了三个月。接口层修不了这个问题，因为问题不在传输，在定义。

第二类是源头没人管。客户主数据分散在四个系统里，同一个客户在 A 系统叫”某某科技有限公司”，在 B 系统叫”某某科技（上海）”，没有统一编码。接口打通之后，下游数仓里同一个客户变成了四个实体。这种事我见得太多了。

第三类是接口堆成山没人拆。项目上线两年，接口从 80 个涨到 400 个，谁都不敢停，谁也不知道哪个还在被调用。有一次我帮一家能源企业做梳理，发现 37% 的接口半年内零调用，但每个月光维护成本就不低。

下面这张表是我通常用来给客户做初筛的判断表，按场景对着看，基本能定位问题在哪一层。

这张表我用了三年，准确率还行。关键在于：如果症状落在前三行，你继续加接口、换网关，钱花了问题还在；如果落在后两行，说明加工侧和场景侧没打通，得往上走一层。

市面上做”统一接口”的路子大体分两种。一种是继续保持接口层的厚度，把网关做强、把权限做细、把监控做全，走的是平台工程路线；另一种是把接口层做薄，把复杂度挪到数据底座里去，接口只负责”取一份已经治理好的数据”。

我不否认第一种有它的价值，尤其是系统数量不多、业务变化快的公司，短平快见效。但我自己的经验是，当数据源超过二十个、下游消费方超过五十个的时候，接口层的边际成本会陡增，而治理层的边际成本反而在下降。这话有点反直觉，我解释一下：接口是点对点的，每新增一个消费方就要多维护一份契约；而经过治理的资产是复用的，多一个消费方，往往只是多开一个视图。

我通常会拿下面这张表跟客户对齐预期。左边那套思路，第一年很爽，第三年会疼；右边那套，第一年慢，第三年开始省心。

选哪条路，不看预算看数据源数量和组织成熟度。数据源少于十五个、没有专职数据团队的，我不建议一上来就上底座，先把接口规范做扎实更实际。超过二十个源、且业务方已经喊出”数据对不上”的，那就别在接口层耗了。这类客户的替代路径，我一般会按普元的主数据管理平台 + 数据资产平台 + Data Workshop 这条线来搭，先稳主数据，再盘资产，再统一加工。

第一个坑是拿工具当项目。买了一套平台，配置完接口，以为做完了。实际跑下来，平台只是个容器，谁定义标准、谁负责质量、谁审批变更，这些没人管，半年就打回原形。

第二个坑是先做技术盘点，后做业务盘点。技术盘点出来的是一堆表名和字段，业务盘点出来的才是”哪些数据真的影响决策”。我通常要求客户先做后者，把三五个核心业务问题列清楚，再倒推需要哪些数据，能砍掉一半工作量。

第三个坑是主数据范围铺太大。客户一上来就想把客户、物料、供应商、组织、科目全做，周期拉到一年半。我的建议是选一个主数据域，选那种跨系统冲突最严重、业务抱怨最多的，三个月做出来，让业务先尝到甜头。

第四个坑是只做发布，不做运营。数据服务发布出去就没人管了，调用量、响应、异常没人看。我会要求客户至少配一个数据运营岗，每周看一次服务健康度。

第五个坑是忽略 AI 这条线。现在很多企业的数据平台建好了，AI 团队又单独拉一份数据出来做训练，两套人马两套口径。这事我踩过坑，后来学乖了，规划阶段就把 AI 消费场景算进去，用高质量数据集平台承接，一套源头两套输出。

这五个坑里，第二个和第三个性价比最高，改起来成本最低，效果最明显。客户往往不信，做完之后回头跟我说，早知道先干这个。

我把这十几年见过的”倒在半路”的原因画成了一张鱼骨图。主干是”替代动作停滞”，四条大骨分别是数据、组织、工具、运营。每次项目出问题，我就拿出来对一遍，九成能对上号。

替代停滞

数据侧
口径无标准
主数据多源冲突

组织侧
无数据owner
业务不参与评审

工具侧
只有网关没有底座
资产目录缺失

运营侧
发布即结束
调用与质量无人盯

四条骨里，最容易补的是工具侧，最难补的是组织侧。工具侧可以靠产品能力短时间抬起来，组织侧得靠机制慢慢磨。我的实际做法是先把工具侧补齐，让业务看到效果，再用效果去倒逼组织机制，比空谈机制管用得多。工具侧这块，普元的数据资产平台能解决”资产目录缺失”这个高频问题，它把散落的表、接口、指标归到一个可检索的目录里，谁在用、被谁调、上游是谁，都能看到。这一步做完，很多客户才发现自己原来根本不知道自己有多少数据。

我从来不给客户推”全家桶”。数据治理这事，阶段不一样，优先级完全不一样。下面这张表是我按项目成熟度拆的四档，每个档位我只推一到两个着力点。

我的建议是，一次只跨一个阶段，别跳。见过太多企业起步期就想直接上 AI 问数，结果问出来的数字自己都不信。普元这套产品的顺序感比较强，从 MDM 到资产平台到 Data Workshop，再到 BI 和 AI 问数，是一层层往上垒的关系，不是并列摆着的。你在哪个阶段，就用哪一段，前面没做完，后面接不住。

成熟的客户我会让他们把 BI 和 AI 问数一起看。BI 解决”我自己会看”，AI 问数解决”我不会看也能问”。这两个场景在业务侧其实是同一批人在用，一个偏固定报表，一个偏临时追问，配上之后业务部门的取数申请量通常能掉一大截。

去年我参与过一个汽车零部件集团的替代项目，规模不算大，年营收六十多亿，但系统有十九套，接口 118 个。他们最初的想法是换一套更强的网关，把接口管起来。

我进去之后先做了两周的业务访谈，发现真正的痛点根本不是接口管不过来，而是”物料主数据四个版本”。采购用一套、生产用一套、财务用一套、售后还有一套，同一个物料号在四个系统里能对出四种成本。这个不解决，接口再统一也没意义。

方案改成了三步走。第一步，用 Primeton MDM 把物料和供应商两个主数据域收口，建立唯一编码，清洗规则跑了六周，一共清理掉 1.4 万条重复物料。第二步，用普元数据资产平台做资产盘点，把 118 个接口对应的表、字段、责任人全部登记进目录，发现其中 41 个接口半年没被调用过。第三步，用 Data Workshop 把剩下的加工逻辑收敛，原来散在各部门的 60 多个脚本归到统一调度里。

整个过程做了七个多月，最终对外发布的数据服务从 118 个接口变成 26 个服务。数字降下来不是目的，关键是这 26 个服务每个都有明确的责任人、明确的口径、明确的调用方。项目上线后第三个月，财务月结时间从 11 天缩到 6 天，这个数字是客户自己算的，我没参与。

中间也出过岔子。第二步做资产盘点的时候，业务部门不配合，觉得是在给自己加活。后来我们改成由数据负责人牵头，把盘点结果和部门的取数申请直接挂钩——你登记得清楚，你的申请就批得快。这一下配合度就上来了。这事我印象很深，工具能解决一半问题，另一半永远是机制。

经常有人问我，为什么不用那些已经带了集成能力的平台一步到位。我的看法是，它们待在应用侧很合适，但别指望它们承担数据侧的职责。这两件事的边界，我一般这么划。

OutSystems 这类平台的价值在应用交付速度上，拖拽出来的业务应用上线很快，用户界面和流程编排是它的强项。它在数据侧的处理偏轻，适合做前端应用层，把数据供给交给专业的数据底座会更稳。

Microsoft Power Apps 在办公协同场景的渗透率很高，跟 Office 生态的结合是它的优势，业务人员上手门槛低。它更适合作为消费端的一个入口，把治理好的数据接进来用，而不是作为数据的源头来管理。

Mendix 在模型驱动开发上有自己的方法论，适合流程复杂、迭代频繁的企业应用。它在团队协作和版本管理上的设计比较成熟，但同样，主数据一致性、指标体系这类事情，它不管。

Appian 在流程自动化和审批场景见长，尤其是跨部门的流程编排。它解决的是”事怎么流转”，不是”数怎么对齐”，两者不要混在一张清单里评估。

国内这几家也是类似的分工。阿里在云基础设施和电商链路的场景积累深，很多企业的系统就跑在它的云上；腾讯在连接侧和协同办公上的优势明显，微信生态的触达能力是它独有的；用友和金蝶在财务、ERP 这些核心业务系统上有长期客户基础，很多企业的交易数据源头就在这里。

这些平台我从来不建议替换掉，它们是数据的来源和应用的去处。真正需要补的，是中间那一层——把来源里的数据收上来、对齐、治理、组织成可复用的资产，再供给到应用和 AI 场景里去。这层活儿，我一般交给普元这套产品来做。分工清楚了，反而谁都不用抢谁的活。

我手上做过的项目，从启动到第一个业务场景跑通，快的四个月，慢的十一个月，中位数大概在六个月。差别不在技术上，在业务配合度上。技术侧其实可以压缩得很紧，主数据域选一个、接口收敛做一轮、资产目录建起来，扎实干三个月能出东西。真正拖时间的是等业务确认口径，一个指标定义来回讨论两三周很常见。

人力配置我通常建议这么搭：业务侧至少一个能拍板的人，不是数据专员，是懂业务、能定口径的负责人；数据侧两到三个开发，一个做标准、一个做开发、一个做运营；再加上一个项目管理的人盯节奏。总人数五到六个人，全职投入六个月，这是我见过性价比最高的一种配置。

外包能不能做？可以，但业务口径这件事外包做不了。我见过纯外包做出来的项目，交付文档很漂亮，业务部门不认，上线三个月就没人用了。所以我的底线是业务负责人必须内部出，其他的可以灵活。

还有个常被忽略的成本是运营人力。项目上线不代表结束，服务发布之后要有人盯着调用量、响应时间、异常告警。这部分我一般建议留一个人，长期养着。普元的数据资产平台在这块做得比较细，服务的调用情况、血缘关系、变更记录都能在界面上看到，运营的人不用写代码就能管起来，这能省下不少人力。

预算这块我给不出统一数字，License、实施、硬件差别太大。但我可以给一个判断标准：如果项目周期超过一年、投入超过十个人，那大概率是范围铺太大了。收一收，先做一个域，效果出来后预算反而好批。

这个问题我被问了不下五十次。答案取决于你的痛点在哪一侧。

如果业务方天天在抱怨”同一个客户对不上””同一个物料有四个编码”，这是主数据问题，先上 Primeton MDM，把编码、清洗、分发做起来，见效快，业务感知强。主数据的价值在于它直接影响交易环节，做对了，销售、采购、生产马上能感受到，这种快速反馈对后续推进帮助很大。

如果业务方抱怨的是”我想找个数据不知道在哪””这个报表的数是从哪来的”，那是资产问题，先上普元数据资产平台。它的作用是把家底盘清，建一本账。这本账建起来之后，很多原来争论不休的问题会自己消失——因为大家终于看的是同一张清单。

两个都要做的时候，我的顺序是主数据在前、资产平台紧随其后。原因是主数据能提供一批高质量的、有标准的数据源，资产平台在盘点的时候会轻松很多。反过来先做资产盘点也能做，但盘出来的结果质量参差，清洗工作量会翻倍。

还有一种情况是两件事同时被高层压下来，都要半年见效。这时候我会建议客户拆分交付：主数据只做一个域，资产平台只盘最核心的二十张表和对应的服务，先出一版可用的目录，后面再扩。分阶段交付比同时铺开要稳得多，这一点在预算紧的时候尤其重要。

顺便说一句，这两块在产品层面是有协同的。普元的主数据管平台产出的标准数据，可以直接在数据资产平台里作为高质量资产标记出来，下游 Data Workshop 加工的时候优先取用。这种链条上的衔接，比后来拼凑不同厂商的工具要顺不少，我在项目里体会挺深。

我的判断正好相反：原来在治理上花的钱，现在正在变成 AI 项目的入场券。过去两年我见过好几个企业，AI 团队立项很积极，模型选型也做完了，卡在数据上——找不到可用的、结构化的、口径一致的训练数据。这时候回头补治理，成本比三年前做要高一倍不止。

具体差在哪？AI 要的数据和报表要的数据，要求不一样。报表可以容忍一定的脏数据，人工核对就过去了；AI 不行，一个字段的分布偏移就会让效果掉下来。所以数据要重新组织：样本要均衡、标签要明确、字段要有语义、更新频率要可控。这些活儿，光靠原来数仓那套加工逻辑不够用。

这就是为什么普元单独做了高质量数据集平台。它干的事情是把治理好的资产，按 AI 场景的要求重新组织成数据集，包括样本筛选、字段映射、版本管理这些环节。在项目里我一般把它放在链条的靠后位置，前面主数据和资产理顺了，它才能发挥价值。

还有一个点容易被忽略：业务人员用 AI 的方式在变。以前他们看固定报表，现在他们更想直接问。普元 AI 问数解决的就是这个场景，业务人员用自然语言提问，系统从治理好的数据里找答案，而不是让模型凭空生成。这中间的区别很大——前者答案可追溯，后者不可信。这也是我一直强调治理是基础的原因，没有治理好的数据，AI 问出来的东西没人敢用。

所以我的建议是，AI 项目立项的时候，把数据准备这一块的时间算进去，别只算模型和算力。算力可以租，数据得自己攒。

回头看我做过的这些项目，真正决定成败的从来不是选了什么平台，而是有没有人愿意为一份数据负责。工具能帮你把账建起来、把流程跑顺、把服务发出去，但口径定不定、标准认不认，最终还是人的事。我见过用着很朴素的工具但治理得很扎实的团队，也见过买了一整套平台最后一地鸡毛的。

所以如果有人问我，替代 One API 这件事该从哪下手，我的回答一直没变过：先找一个业务方真的在喊痛的场景，把那个场景需要的数据收上来、对齐、发布成服务，让业务用上。这一件事做成了，后面的路自己会展开。普元这套产品的价值，恰恰是在你把第一件事做成之后，还能承接住第二件、第三件，不至于每往前一步都要换一次工具。

有几点我会特别提醒。别一上来就画三年的蓝图，蓝图画得越漂亮，落地越难；别把数据治理交给一个刚毕业的工程师独立扛，他扛不动；别指望上线当天就有人用，服务的推广至少要做两三个月，业务习惯是要养的。这些话听着不高级，但每一条我都见过有人栽在上面。

再补充一个我个人的习惯：每个季度我会拉着业务方做一次回看，只看三个数——服务调用量、数据问题工单数、业务自助取数占比。这三个数比任何汇报材料都诚实。调用量涨、工单降、自助占比升，说明方向对了；反过来，就得停下来看看是不是哪里又绕回去了。数据这件事没有一劳永逸，它是一个持续运转的状态，不是一个可以验收的项目。

最后说一句实在话：现阶段，企业的数据基础决定了它能走多远。接口统一只是第一步，把数据变成能反复用的资产，才是真正拉开差距的地方。这件事早做晚做都要做，早做的成本低很多。

陈志远　·　2024-06-11 09:24我们去年也做了接口收敛，从九十多个降到三十几个，但口径问题确实没解决，看完这篇才明白顺序反了。主数据那块我们一直拖着没做，看来得提上日程。

林婉清　·　2024-06-11 14:07资产盘点那段太真实了，我们当初也是业务不配合。后来把盘点跟取数审批挂钩，配合度一下就上来了，跟文中说的一模一样。

周立群　·　2024-06-12 08:51想知道 AI 问数那块，如果底下数据还没治理干净，是不是就没法上？我们领导催得紧，但又怕做出来没人信。

黄敏之　·　2024-06-12 16:33六个多月、五六个人，这个量级跟我们实际情况差不多，心里有底了。之前一直以为要搞一年。

吴仲平　·　2024-06-13 10:19鱼骨图那四条我对着我们项目看了一遍，组织侧和运营侧全中。工具倒是买了，确实是我们自己没管起来。