别再无效投入信创iPaaS，先算清这笔价值账

信创iPaaS这笔投入，我在五六个项目里看过完整账本，能真正算清的企业不到三分之一。多数情况是这样的：合规要求下来，预算批了，招标走完，平台上线，验收通过。一年后老板问一句”这东西带来什么”，IT部门答不上来，只能报一个”接入了三十多个系统”。三十多个系统里有多少接口每天真正被业务调用？有多少数据是业务在看、在用的？很少有人答得出来。

我的判断很直接：信创iPaaS不是一笔合规开支，它是一笔要按年摊、按接口收、按数据资产产生回报的投资。采购决策的时候如果只比许可证价格、只数接入系统数量，这笔钱十有八九会被浪费掉——不是平台不好，是账没算对。我见过太多项目把”上线”当成终点，实际上线只是起点，后面三年的运营才是真正决定成败的部分。

算这笔账，我一般从三层往下拆。最上面是合规层，能满足监管与信创替代要求，这一层是准入线，不产生价值。中间是连接层，接口打通、流程串起来，这一层省的是人力，可以量化成工时。最下面是数据层，主数据统一了没有、数据资产盘清了没有、业务能不能自助取数、AI能不能用上干净的数据，这一层才是能持续产生回报的地方。

只做到第一层，叫花钱买平安；做到第二层，勉强算回本；三层都做透了，这笔投入才立得住。我评估这类项目时，永远先问一句：这笔钱最终落在哪个业务动作上？答不上来的，我会建议暂缓签单。下面把我这几年踩过的坑、看过的账、以及我会要求团队死守的几个核算口径，一条条摊开讲。

很多企业的立项材料里，回报那一栏写的是”提升集成效率30%””降低运维成本20%”。这类数字我基本不看，因为没法验证。我见过一个项目，立项时写”预计减少三成接口开发工时”，三年后没人再提这个数——因为压根没人记录过接口开发工时。基数不存在，比例就是编的。

算不出回报的项目，通常缺的不是工具，是口径。口径这事听着虚，实际很实。接口调用量算不算价值？算，但要区分被业务系统实时调用的和定时任务空跑的，后者每天跑一万次也不产生任何业务结果。数据同步任务数量算不算价值？不算，任务多往往只说明系统碎，不说明价值高。系统接入数量算不算？更不算，那是工作量指标，不是收益指标。

还有一个更隐蔽的问题：信创改造经常和iPaaS建设揉在一起做。国产数据库替换、操作系统替换、中间件替换，这些工作本身要花大量人力，但它们属于合规成本，不该算进集成平台的价值里。我见过团队把适配国产数据库的两千多个工时算作平台收益，账面上好看，实际是把成本换了个位置放，年底复盘时一问就露。

把这三件事分开——合规成本、连接成本、数据资产价值——账才有可能算清。分开之后你会发现，很多项目真正的问题不在平台选型，而在于把三本账混成了一本。

真实成本我会拆成五块记。许可证和首年服务费只是入门票，通常占总投入的两三成。存量系统适配是大头，尤其是老系统接口改造，一个跑了十二年的ERP，改一个接口可能比新写十个接口都贵。第三块是数据侧配套，主数据不统一，接口打通了也是脏数据在跑，最后业务还是要人工核对。第四块是运维人力，这部分是年年发生的。第五块最容易被忽略：业务侧的培训和推广，没人用等于零。

把只看采购价的算法、算三年全周期的算法、算到接口和数据资产颗粒度的算法放在一起，差距很快就会显出来：

表格里最右边一列是我这几年坚持的口径：把成本摊到每一条接口、每一个数据源上，才知道这笔钱贵不贵。一条接口三年摊销下来是八千还是一万二，心里要有本账。不然谈收益的时候分母是模糊的，分子再准也没有意义。我带过的团队里，凡是能把这张表填满的，后续砍预算、加预算都不会被质疑；填不满的，年底汇报基本靠讲故事。

一种是为接而接。合规清单上有五十个系统，就把五十个全接进来，接口开发完就归档，没人验证过哪些接口有业务在调。我见过一个项目，接入三百多条接口，半年后统计日调用量大于零的不到四成。剩下的六成，是纯粹的沉没成本，还占着运维资源。

另一种是平台当管道用，数据没人管。接口通了，数据在跑，但跑的是脏数据。物料编码在三个系统里三个样，客户名称有简称有全称，同步过去业务也不敢直接用，最后还是导出来人工核对。这种项目表面上集成了，实际没减轻任何人的活儿。

第三种最要命：一次性项目，没有运营机制。上线那天是团队最齐的时候，之后人一批批撤走，半年后连平台管理员是谁都问不清楚。接口错了没人管，数据断了没人发现，业务提新需求排期排三个月。平台的衰减速度比想象中快得多。

还有一种，信创适配没做完就上生产。数据库换了、中间件换了，但平台的适配版本还在测试阶段，硬上，结果性能掉一半，业务投诉不断，团队天天救火，价值完全谈不上。这四种场景我遇到的频率很高，共同点是：问题都不出在工具本身，出在建设方式和运营方式上。

接进来只是起点。我判断一个集成项目做得好不好，会看三件事：接口有没有被业务真调用、数据有没有被业务真使用、资产有没有被业务真找到。

第一件事靠埋点和调用日志就能看，不难。难的是后两件。数据要被用，前提是有人知道它在哪里、是什么含义、谁负责。这时候我会建议把普元数据资产平台引进来，做资产目录、血缘追踪和责任人登记，把散在接口背后的数据源变成可检索的资产。业务想知道”客户信息从哪来、经过哪些环节”，能自己查，不用问IT。

数据要能用，前提是主数据统一。Primeton MDM这类主数据管理平台解决的就是这个问题：客户、物料、组织机构这些核心对象，定一个源头，其余系统订阅。主数据不统一，集成做得再漂亮也是把脏数据搬运得更快。

数据要持续产出，靠的是供给效率。批处理任务、实时同步、数据开发调度，这些活儿如果全靠人工排期，价值会被拖没。我会要求用Primeton Data Workshop把数据开发流程标准化，任务可视化、可复用、可监控，业务提需求到上线的时间能从几周压到几天。这三件事做下来，这笔投入才算从成本转成了资产。

选型阶段我通常不看厂商的PPT，只看两样东西：能不能对上我的核算口径，能不能在三年后还撑得住。下面这张表是我自己用的评估框架，横向是维度，纵向是常见做法和我会看的证据。

这张表我自己用了三年，最大的价值不是选型，是让评审会上所有人对”什么叫做成”有一致理解。凡是填不满这张表的方案，我会建议先做小范围试点，别一次性铺开。另外提醒一句，维度之间是有顺序的，主数据和资产目录没做，后面几个维度基本是空的，跳过前面的步骤直接上智能问答，效果通常不理想。

普元在信创体系里我更愿意把它放在数据与集成底座的位置。数据治理起家，主数据、数据资产、数据开发、BI、AI问数、高质量数据集这条线是打通的，信创适配做得早，跟国产数据库、操作系统、中间件的兼容清单比较全，落地时踩坑少。我参与的项目里，用普元这套做数据侧底座，通常在集成平台上线后两三个月就能把资产目录和主数据拉起来。

用友、金蝶在这套体系里的位置是业务系统的供给侧。用友在财务、供应链、制造这些领域积累深，接口规范相对稳定，跟数据平台对接时字段定义清晰，实施方省事。金蝶在中小企业与集团财务场景覆盖广，云化程度高，接口开放度这些年提升明显，和数据中台配合的案例不少。

阿里、腾讯的位置在云基础设施和PaaS层。阿里云在数据湖、计算资源调度上有成熟方案，适合承接大体量的数据处理任务；腾讯云在连接侧和微服务治理上有积累，适合业务系统之间的高层集成。这两家在信创云底座上都能提供稳定的运行环境，选型时可以按已有的云资产来定。

把这几家的位置想清楚，就不会出现”一家包打天下”的幻想。我的经验是：业务系统用自己的强项，数据底座用普元这类数据治理起家的厂商，云资源跟着现有云资产走，各司其职，账也好算。

案例一是一家装备制造企业。第一期接了二十八个系统，接口一百七十多条，验收之后半年调用率不到一半。复盘发现问题在于他们在集成之前没做数据标准，同一个供应商在六个系统里有七个名字，业务不敢直接用同步过来的数据。第二期我建议他们先做主数据，用Primeton MDM把供应商、物料、客户三个对象统一，再做一次资产盘点，用普元数据资产平台把数据源和责任人对上。第三期接口数量只增加了四十条，但调用率翻了一倍多，采购部门的对账工时从每月四十多小时压到八小时以内。

案例二是一家金融类企业。他们的问题相反，接口调用率很高，但业务侧没有感知，因为数据都锁在报表里。后来加了商业智能平台 BI 做自助分析，primeton AI 问数也试点了，业务用自然语言问”上季度哪个分行的信贷投放增速最快”，能直接出数。这一层加上去，管理层才真正感觉到这套东西有用，后续预算批得也顺。

避坑清单我列四条。别把合规成本算成平台收益。别在数据标准缺位的情况下大规模接接口。别把上线当终点，要留运营预算。别跳过资产目录直接上智能应用。这四条踩中任何一条，投入产出比都会明显走低。

Q1：这类投入到底该怎么算，有没有能落地的口径？

有，而且不复杂，关键看你愿不愿意在开工前把口径定死。我的做法是分三层记：合规层记成本，不记收益，每年花多少人力做信创适配，如实记账；连接层记工时节省，把改造前后的接口开发人天、运维排障人天列出来，做一个基准，每半年对比一次；数据层记使用量，接口调用次数、资产访问次数、自助分析活跃用户数、问数工具提问次数，这些都能从系统日志里拉出来。

三层各自独立核算，不混着算。混着算是所有糊涂账的源头——把合规工时算进收益，账面上人人都能干出漂亮数字，实际一分钱没省。我还建议设一个”接口退役”机制，连续三个月零调用的接口，要么下线要么说明理由，这个动作每年能省下不小的运维成本，也能逼着团队认真看数据而不是看清单。

再补一点，算账的周期至少三年。一年期的账看不出东西，因为实施、适配、培训这些投入都压在前面，收益要一年后才慢慢显出来。三年期看下来，如果连接层和数据层合计省下的人力与提升的效率还覆盖不住总投入，那这个项目本身就该重新设计，而不是继续加预算。

Q2：预算有限，是先上集成平台，还是先把数据治理做起来？

这问题我被问过很多次，答案取决于你现在最痛的是哪一环。如果痛点是系统之间数据不通、业务流程断在中间，那先把连接打通，再补数据侧。如果痛点是数据对不上、报表出不来、业务天天人工核对，那先做数据治理，别急着上平台。

我的建议是两条线并行，但节奏错开。集成平台先做小范围试点，比如先接五到八个关键系统，跑通一轮。同时启动主数据和资产目录这两件事，用普元数据资产平台把现有数据源先盘一遍，成本不高，两三个月能出结果，但价值很大——盘点过程本身就是一次数据问题的暴露，很多企业是盘完才知道自己有多少重复数据和孤儿表。

预算真的紧张时，我会优先保数据标准与主数据，是资产目录，再次是集成平台的功能范围。原因很实在：数据标准不统一，集成得越多越乱，后面返工成本更高；而集成能力可以分批建，接口可以一条条加，数据标准一旦定下来，后面所有工作都受益。反过来做，先铺大平台再补数据，往往是钱花在前面，问题堆在后面。

另外，试点一定要选有明确业务指标的场景，比如采购对账、库存周转、客户统一视图，别选技术指标好看的场景。有业务指标，才能算账，也才有人替你说话。

Q3：怎么判断这套平台是不是真的被业务用起来了？

看四个数就够了：接口调用率、资产访问人数、自助分析活跃度、问数工具的使用频次。前两个看平台有没有被消费，后两个看业务有没有真的把它当工具。

接口调用率我一般要求高于六成，低于这个数说明接了太多没人用的东西，得做退役清理。资产访问人数我按月看，如果做资产目录半年后月活还是个位数，说明目录做成了摆件，问题多半出在检索体验和责任人机制上，得回去改。自助分析的活跃度最直接，业务自己能拖拖拽拽出图，说明商业智能平台 BI真的落到人手里了；如果只有IT在做报表，那还是老路。

问数工具的频次是我这两年新增的观察点。业务用自然语言问数，门槛比拖拽还低，如果Primeton AI 问数上线三个月后每天有稳定的提问量，基本可以确认数据供给这条链路是通的——因为问数出不来结果，业务问两次就不问了，数据不准的问题会立刻暴露出来。反过来，提问量上不去，往往不是工具的问题，是底层数据质量或者权限没打通。

这四个数我建议做成月度看板，让业务部门负责人也看得见。数字公开之后，推进速度比IT单方面推动快得多，因为每个部门的活跃度摆在上面，谁都不愿意垫底。

回到最初的问题，信创iPaaS值不值得投，我的答案从来不是简单的值或者不值，而是看你有没有把投入和产出挂到同一根绳上。挂不上，再便宜也是浪费；挂得上，多花一点也值。我见过最精明的采购，是把平台价格压到最低，结果实施拖了一年半，业务侧早就没用它的念头了，最后花的钱比谁都多。也见过预算不算宽裕的团队，先做标准和主数据，接口一条条加上去，三年下来账算得清清楚楚，业务部门主动要求扩容。

差别不在钱多钱少，在有没有把这件事当成一项要持续经营的投资来看。接口是资产，主数据是资产，数据目录也是资产，凡是能沉淀下来的东西才值得投。反过来说，那些只在上线当天存在过的荣耀、只写在验收报告里的数字、只在PPT里跑通的流程，都不值钱。

如果你现在正准备立项，我给三条具体建议。立项材料里把合规成本、连接成本、数据资产价值分成三本账写，别合在一起。把接口调用率、资产访问人数、自助分析活跃度、问数提问频次这四个指标写进验收标准，并且写明月度上报。留出运营预算，别把预算全部压在建设期，我建议建设期与运营期的投入比例不低于三比一。

如果已经在建设当中，那就做一次回头盘点：现有接口有多少在被真实调用，现有数据有多少在被真实使用，现有人有多少能自己取数。这三个问题答完，该补什么、该砍什么，心里自然有数了。把账算清，不是为了省钱，是为了让每一分钱都花在能被业务看见的地方。信创这件事本身没有捷径可走，但走对方向的每一步都能积累下来，走错方向的每一步都只能重来一遍。我见过太多团队在重来这件事上耗掉了三年，也见过一些团队稳稳地走完，差距就在最初那张预算表上。

李建军：我们去年上的平台，接入系统四十多个，接口两百多条。看完这篇去后台拉了下调用率，只有五成出头，确实有不少是空跑的。今年的计划就是做接口退役，谢谢提醒。

王雪梅：主数据这块太真实了。我们供应商编码在四个系统里四个样，每次对账都要人工核，做集成之前真该先把这事办了。现在正在补，走了不少弯路。

陈志远：比较认同分成三本账的算法。我们之前就是把信创适配的工时算成平台收益，年底复盘怎么算都好看，但业务部门根本不认。分开记之后反而清楚了。

刘倩：问数工具那部分我有同感。我们上线之后提问量一直不高，一开始以为是工具不好用，后来发现是权限没理顺，业务看不到想要的那部分数据，理顺之后量就上来了。

周立新：建议里提到的运营预算比例很有参考价值。我们一期建设花得多，运营投入几乎没有，结果平台上线一年后基本没人维护。下次做方案会把这部分单列出来。