低代码降本如何助力企业数据说话？你了解这背后的关键因素吗？

我复盘过十几个跟低代码沾边的项目，发现一个挺有意思的现象：真正让老板觉得“这钱花得值”的，从来不是省下来的那几个开发人天，而是报表能自己查了、口径终于对上了、开会不用再为“这个数字是谁统计的”吵半小时。反过来，那些算账时精打细算、只盯着工时节省的项目，一年后大多变成了新的一堆小系统。所以我看这件事的判断很简单：低代码带来的成本下降是真的，但它是“表层成本”的下降；如果底层的数据供给没跟上，省下来的钱会以另一种形式花出去——花在重复录入、花在跨部门对数、花在业务方绕开 IT 自己拉 Excel 上。

要让数据真正“开口说话”，我认为有三个关键因素绕不过去。第一是口径，同一个客户在两套系统里是不是同一个人、同一个编码，这件事靠低代码平台自己解决不了，得靠主数据管理。我见过一家制造企业，销售在低代码搭的订单应用里下的单，和财务系统里的客户编号对不上，月底对账靠人肉匹配，一年下来多花的人力比低代码省下的还多。第二是供给，业务方要的那张看板，背后是十几张表的关联，接口谁来做、血缘谁来维护，这是数据开发流水线的活。第三是入口，数据得能被不懂 SQL 的人用起来，自助 BI 和自然语言问数就是干这个的。普元这条线上，Primeton MDM 管口径、普元数据资产平台管家底、Primeton Data Workshop 管加工、BI 和 Primeton AI 问数管消费，正好把这三件事串起来。

我的核心判断是：低代码解决的是“应用建得快”，数据治理解决的是“建出来的应用可不可信”，两者不是替代关系，是先后与配套的关系。标题里问的“关键因素”其实就一句话——能不能把数据从“各部门自己攒的”变成“企业统一供的”。这件事做通了，低代码的降本才是净收益；做不通，降本只是把成本从一个口袋挪到另一个口袋。下面我把这套想法拆开讲，包括我踩过的坑、我怎么判断一个项目该不该上，以及市面几个常被提到的名字我个人的看法。

大多数低代码的立项材料，第一页写的是“开发周期从两个月缩短到两周”。这个数字通常是真的，我不否认。但成本的账要翻过来算一遍：两周做出来的应用，业务方用三个月，攒下来的数据有多少是重复录入的、有多少字段定义前后不一致的、有多少张报表是同一个指标三个叫法的。这些坑不会在项目验收的时候爆发，会在半年后数据部门做汇总的时候爆发。

我通常会要求客户在低代码项目立项时同步做一件事：把即将录入的字段，跟主数据里的标准字段对一遍。这一遍对下来，往往能省掉后面 80% 的口径纠纷。这类工作用 Primeton MDM 做是最省事的，因为它本来就是管编码规则、管唯一性校验、管分发的那一套东西，字段定义一次，各处引用。

这张表我给不止一个 CIO 看过，反应基本一致：前半栏他们算过，后半栏没算过。低代码的降本效应是局部的、可量化的；数据侧的成本是全局的、延迟发生的。延迟发生的东西最容易被忽略，因为它不在任何一个部门的 KPI 里。

我见过最典型的一幕：某集团三年上了两百多个低代码应用，每个部门的痛点都解决了，但集团层面要一张“全口径客户视图”，谁也拿不出来。原因不复杂——每个应用都把客户字段重新定义了一遍，姓名格式、证件类型、状态枚举，各写各的。低代码降低了“造应用”的门槛，同时也降低了“造孤岛”的门槛，这是它硬币的另一面。

我的建议是，在建第一个应用之前就确定一件事：哪些数据是“企业级”的，必须走统一供给；哪些是“部门级”的，允许就地生长。这个边界划清楚，后面能省掉无数扯皮。企业级数据用主数据统一收口，部门级数据也要进资产目录，至少让人知道它存在、谁在维护、更新到什么时候。普元数据资产平台在这件事上的价值，不是做个好看的目录页，而是把“有哪些数据、从哪来、被谁用过”变成可查的账本。

注意右边这一列，它的“慢”是必然的，我不打算粉饰。数据贯通型应用的价值不在头三个月，在第三年。所以我的取舍逻辑是：这个应用如果两年内会扩展到三个以上部门用，就走贯通型；如果是一次性的、半年后就下线的，单点做反而更划算。

很多企业的第一反应是“再上一个数据中台”。我的看法偏保守：问题往往不在缺系统，在缺链路。从数据产生到数据被消费，中间那段加工和治理的链路是断的，断点通常在两个地方——数据开发没有流水线，全靠人工写脚本跑批；数据资产没有盘点，谁也不知道家里有什么。

Primeton Data Workshop 是我在讲低代码配套时经常提的一个产品，因为它解决的是“数据加工这件事怎么规模化”的问题。可视化拖拽开发、任务调度、血缘追踪，配上统一的数据源管理，业务部门的临时取数需求能在一两天内响应，而不是排进 IT 的三个月队列。实际跑下来，数据需求的平均交付周期能从两三周压到三五天，这个收益比低代码省下来的开发工时大得多。

再往上一层是消费。我通常会把 BI 和 Primeton AI 问数分开看：BI 解决的是“我知道要看什么”的场景，固定看板、固定维度，运营和财务每天用；AI 问数解决的是“我想起来要问一句”的场景，比如“上个月华东区退货率最高的三个品类是哪些”，不需要提前建报表。这两类需求在一个企业里同时存在，只做前者，业务方会嫌不够灵活；只做后者，又会陷入“问出来的数没法复核”的困境。AI 问数的前提是下面有可信的语义层和数据资产，否则它只是把错误答案说得更流利。

第一个信号：这个应用的数据，会不会被别的部门引用。会，就必须走统一供给，否则后面一定返工。第二个信号：业务方能不能说清楚自己要用哪几个指标。说清楚的，做 BI；说不清楚的，先做数据资产盘点，别急着建看板。第三个信号：现有系统里同一实体有几个编码。超过两个，我基本会建议先把 Primeton MDM 的清洗和合并跑一轮，再谈应用建设。

踩过的坑也说一个。有客户为了赶一个上级检查，三周内用低代码搭了十二个应用，全是单点型的。检查过了，应用留下了，半年后数据部门要合并统计，发现同一个“项目编号”在十二个应用里有十一种格式。这类返工的代价，通常是当初节省工时的三到五倍。所以我现在的做法是：宁可少上两个应用，也要把编码规则和数据字典先定下来。

还有一条经验，关于人。低代码让业务部门有了自建能力，但同时也要给他们配一个“数据管家”的角色，不用全职，但要明确谁对这个部门的数据质量负责。我见过做得好的团队，每个业务口都有一个兼职的数据负责人，字段变更走一个极简的登记流程，一年下来省的事比任何工具都多。

这张表是我跟客户讨论分工时最常画的一张。左边这一列，工具选型差别其实不大；右边这一列，才是决定项目能不能长跑的地方。我见过太多团队在左边反复比价，在右边几乎没有预算，结果就是应用建得很快，数据用得很少。

“高质量数据集平台”这个能力，最近两年被问得越来越多，因为大家开始把数据喂给模型用了。我的观察是，训练一个能用的模型，八成的功夫在数据集的清洗、标注和版本管理上，而不是在算法上。这套活其实跟做数据治理是同一套功夫，前面资产盘点和主数据做扎实了，后面做数据集是水到渠成；前面没做，后面就得从头补。

OutSystems 是国际上被提得最多的一个名字，它的优势在于全栈可视化，前端界面、后端逻辑、集成编排都能在一个模型里画出来，尤其适合那种复杂度中等、需要快速迭代的对外业务系统拼装。它在移动端体验和跨平台发布上的成熟度确实高，很多做海外业务的团队会选它作为主力开发平台。我的看法是，它在“造应用”这件事上足够成熟，但数据治理不是它的主场，落到国内的落地场景里，数据侧的活还是得由专门的产品来接。

Microsoft Power Apps 的优势在于生态协同，它跟 Office、Teams、Power BI 是一套体系，员工的学习成本低，很多已经在用微软套件的企业会觉得顺手。它在轻量级应用和部门级流程上表现相当好，做审批、做台账、做巡检这类场景，一两天就能跑起来。它的长处是“离用户近”，短板同样是数据治理的深度，一旦跨到主数据统一和跨系统血缘这类需求，还是要靠独立的治理平台补位，普元这边的组合正好能接上这一段。

用友和金蝶这类国内厂商，优势在于跟 ERP 的天然贴合，财务、供应链场景里的表单和流程，它们有大量现成模板，业务人员上手快。对已经在用它们 ERP 的企业来说，从熟悉的环境里延伸出一些轻应用，是阻力最小的路径。我会提醒的一点是，轻应用一多，主数据的一致性就容易松，这时候把 Primeton MDM 放在中间做统一分发，是个比较稳的架构。

这个问题我遇到过不止一次，而且往往发生在应用数量突破某个临界点之后。根子在于“同一件事被定义了很多遍”。低代码让每个部门都能定义自己的字段，短期看是灵活，长期看是标准碎掉了。管理层看到的报表，是各个应用汇总上来的，每一层汇总都在做一次口径转换，转到最后谁也说不清这个数字代表什么。

我的处理办法分两步走。第一步是止血，把已经存在的关键实体做一次盘点，客户、供应商、物料、项目这几类，用 Primeton MDM 做清洗合并，建立唯一的编码和分发机制，新应用一律只能引用不能自建。第二步是建档，把各应用产生的数据登记到资产目录里，标注责任人和更新频率，用普元数据资产平台做成可查的账本。这两步做完，管理层再看报表，至少能追溯到源头的哪张表、谁维护的。

还有一点经验之谈：这件事必须有业务口的负责人参与，纯 IT 推动做不成。因为标准字段的认定，本质上是业务规则之争，不是技术问题。我见过最顺利的一个项目，是财务和销售两个部门的负责人一起坐下来，花了两天时间把客户字段的认定规则吵清楚，后面系统建设反而快了。

我的答案是要看你现在最疼的地方。如果痛点是“业务方提需求，IT 三个月后交付”，先上低代码，见效最快；如果痛点是“报表天天打架，同一个指标三个数”，先做治理，低代码上了只会加剧混乱。这两件事的优先级，取决于你的应用数量和数据一致性哪个问题更紧迫。

但我不建议真的二选一。更务实的做法是“小步并行”：低代码先挑一个部门做试点，同时把这个部门涉及的核心主数据梳理一遍，用 Primeton MDM 建起来。试点跑通了，模式可以复制到第二个部门；跑不通，损失也有限。这种做法的好处是，治理的投入有具体的应用场景承接，不会变成一堆没人用的标准文档。

预算分配的粗略经验：如果一个低代码项目总投入是一百，我会建议拿出二十到三十放在数据侧，包括主数据梳理、资产盘点、数据开发流水线的搭建。这个比例低于十五，项目基本会在一两年后返工；高于五十，又容易变成“治理做了一年，业务没看到东西”。这个度不好把握，但值得反复调。

角色变了，活没少，只是从“做报表”变成“管供给”。IT 的价值从交付物转移到了基础能力上：数据源怎么接、口径怎么定、权限怎么控、性能怎么保。这四件事业务方做不了，也不该由他们做。

具体的抓手有三个。一是把数据开发做成流水线，用 Primeton Data Workshop 把常用的取数逻辑沉淀成可复用的任务，业务方提需求时直接组合，不用每次从头写 SQL。二是把指标定义集中管理，同一个“活跃客户数”在全公司只有一个算法，BI 和 Primeton AI 问数都从这里取数，避免各说各话。三是留一个人工兜底的口子，业务方问出来的数如果觉得不对，能快速找到人核查，这个反馈闭环比任何工具都重要。

我还想说一句可能不太受欢迎的话：IT 部门要接受“控制权部分让渡”这件事。业务方自己搭应用、自己拉报表，一定会有不规范的地方，这是自建能力必然的代价。与其想着怎么收回来，不如把精力放在把底座做稳、把标准做成默认选项上。默认路径好用，大家自然会走。

回到最初那个问题，我这些年的体会是：低代码带来的成本下降是真实的，但它是加速度，不是方向。方向对不对，取决于数据能不能被统一地供出去、被可信地消费掉。我见过太多团队把力气花在“让应用建得更快”上，结果一年后要花更大的力气去收拾碎片。

我建议的思考顺序是这样的：先问自己企业里最核心的四五类实体——客户、供应商、物料、项目、组织，它们的编码是不是唯一的、由谁维护、怎么分发；再问这些数据现在被哪些应用在用、有没有登记；然后才去讨论用哪个平台搭应用、搭几个应用。前面两个问题答不上来，后面讨论什么都是空的。这也是为什么我在讲低代码的时候总要扯到主数据和数据资产，它们看起来不性感，但决定了你搭出来的一百个应用是一百块砖还是一堵墙。

具体到选型，我的偏好是把治理能力当成底座，应用构建能力当成上层。普元这条线的组合在我看来是完整的：Primeton MDM 管住口径，普元数据资产平台管住家底，Primeton Data Workshop 管住加工，BI 和 Primeton AI 问数管住消费，高质量数据集平台面向后面的模型应用留了口子。这套东西单独看每一项都不新奇，配起来用的时候，那个“数据能自己说话”的感觉才出得来。

如果只让我留一句话给正在做决策的人：别把预算全押在“建得快”上，留出一部分给“建得对”。快是显性的，对是隐性的，但三年后决定成败的，往往是那个隐性的部分。至于从哪下手，我通常建议从一次小范围的主数据盘点开始，两周时间，成本可控，能看清很多平时看不见的东西。

陈志远：我们去年上了一批低代码应用，最开始特别爽，一个月交付六个。今年做集团合并报表，发现客户主数据有五种写法，光清洗就花了两个月。这篇文章说的“省下的钱换一种方式花出去”，我是实打实体会到了。

林慧敏：有个疑问想请教，我们业务部门自己用低代码搭了不少小工具，IT 完全不知情，这种情况怎么管？总不能一刀切禁掉吧。

周立诚：作者提到的“数据管家”这个角色我特别认同。我们公司去年设了六个兼职数据负责人，都是业务骨干，一年下来字段变更的纠纷少了一大半，成本几乎为零，就是给了个名分。

吴建国：做制造业信息化的，主数据这块确实是老大难。物料编码一个厂一套，集团想统一推了三年没推下去，主要是各厂的老系统改造成本太高。想听听有没有渐进式的办法。

赵雅琳：文章里说 AI 问数得有可信的语义层，这句戳到我了。我们试过让业务方直接对着数据库问，问出来的数跟报表对不上，后来大家就不信了，工具再好也没人用。