低代码推广的方法论是什么？如何有效实施这些方法来提升业务效率？

低代码推广这事，我做了几年，见过太多企业第一年热火朝天、第二年应用躺在角落里长灰。我的判断很直接：低代码推不动，八成不是工具选错了，而是业务侧搭出来的东西“跑不起来”。表单能画、流程能配、看板能拖，可真进了车间、进了审批流、进了月度经营会，数据对不上、口径不一致、跨系统拉不通，业务人员用三次就回去了。所以我看低代码推广的方法论，第一层从来不是培训、不是考核、不是先做几个漂亮样板应用，而是先把“数据能不能被复用”这件事解决掉——这是我这几年反复验证过的顺序。普元在这一层的价值就比较清楚：易数系列的主数据管理平台、企业数据资产管理平台、数据开发平台，加上普元AI问数和高质量数据集平台，解决的是“低代码搭出来的应用有没有干净数据可用”这个前置问题。顺序反了，推广就是给业务部门添活儿；顺序对了，低代码才真的变成效率工具。

我通常会先做一件事：把客户过去一年搭出来的低代码应用拉个清单，看活跃度。实际跑下来，活跃应用的共同点不是界面好看，而是背后有一份稳定的数据源。那些三个月没人打开的应用，基本都能找到一个共同病因——数据靠手工导入、靠 Excel 中转、靠某个业务员每周更新一次。存量一乱，应用就死。低代码把“做界面”的门槛降到了接近零，于是问题全部后移到数据侧，这是很多人推广时没算到的一笔账。

推广节奏我一般拆成四段看，每段的指标完全不同。用工具数量、应用数量考核，早期好看，后期全是僵尸应用。

我发现一个规律：推广做得成的企业，路线都选得很窄。想同时把业务自助、流程自动化、数据分析三件事一次推完的，基本都散了。这事我踩过坑，早期给客户做方案，恨不得把所有能力都铺开，结果业务部门学了一堆按钮，业务问题一个没解决。后来我改成一个季度只推一条主线，剩下的能力按需放出。

下面这张对比表，是我跟客户开第一次方案会时基本都会画的东西，用来逼他们做选择。

带过几个制造业和能源类的客户之后，我的排序基本固定：先把“人”和“客户”两类主数据统一，再谈应用扩散。为什么是这两类？因为它们几乎出现在每一张表单、每一条流程、每一个看板里，是所有低代码应用的公共依赖。员工编号在 HR 系统里是一个值，在 ERP 里是另一个值，在车间考勤表里又是手工填的，业务人员每搭一个应用就得重新对一次账，这种消耗比学习搭建本身还大。

落地路径我一般这么走：先由普元主数据管理平台把人员、客户、物料这几个核心域的标准定下来，做清洗和去重，形成唯一可信的数据源；再用普元数据开发平台把散在 ERP、MES、财务系统的数据抽过来加工，形成业务能直接用的宽表；然后才开放低代码搭建，让业务在自己的场景里取数。这个顺序看起来慢，实际跑下来，第二个月开始业务部门会主动来要数据源，而不是被动等着被培训。

第一个坑是把培训当推广。我见过企业一年办了二十多场培训，参训率 100%，应用数不到十个。培训解决的是“会不会点”，不解决“值不值得用”。业务人员的判断标准很朴素：这个东西能帮我少加两天班吗？答案是否定的时候，培训再多也没用。

第二个坑是考核指标选错。按应用数量考核，就会出现大量“一人一应用、一次就废弃”的垃圾数据；按部门覆盖考核，就会催生一堆演示型应用。我后来改成看“复用率”和“月度活跃应用数”，指标难看了，但真实。

第三个坑，也是最贵的那个——低代码平台上线了，数据治理没跟上。业务搭出来的报表两套口径打架，管理层在会上当场质疑，整个项目直接停摆。这种事故一次，团队三年内都不敢再提低代码。

我把这一层拆成五件事来看，每件事都对应一个具体的验证动作，不靠演示，靠试。普元这套组合我跟过实际项目，衔接最顺的一点是主数据和数据开发是同一条线上的，不用再拼第三方。普元企业数据资产管理平台负责把有哪些数据、谁在用、质量如何盘清楚；普元高质量数据集平台负责把面向具体场景的数据集打包交付，业务人员拿到的是“可以直接喂给应用”的东西，而不是一堆原始表。

普元AI问数这一块我特别想提一句。业务人员不太关心底层是什么模型，他们关心“我问一句话，能不能直接出数”。当底下的主数据和数据集是干净的，这个体验才成立；不干净的话，问出来的数比不问更危险。所以我在项目里会把普元AI问数放在数据治理之后上线，先小范围开放给三五个业务骨干试，跑通了再铺开。

低代码平台本身怎么选，我一般不给标准答案，因为差异太大。海外几家里，OutSystems 的模型驱动做复杂企业应用比较扎实，适合有专职 IT 团队的中大型企业；Microsoft Power Apps 与 Office、Teams 结合紧密，员工上手门槛低，适合已经深度使用微软体系的公司；Mendix 在业务与 IT 协同建模上做得细，工程化管控能力强；Appian 强在流程自动化，审批密集型的组织用起来顺手。这几家的共性是平台能力成熟，共性是许可成本不低，也都不会替你解决数据问题。

国内几家里，阿里的低代码能力与钉钉生态绑得紧，内部协同场景铺开快；腾讯的低代码与微信生态衔接自然，面向外部用户的小程序类应用省事；用友的低代码平台与其财务、供应链积累结合，财务业务一体化场景有优势；金蝶的低代码平台在财务与集团管控方向积累深。这几家的优势都在“与自己既有产品线连得上”，选型时看企业已经在用谁的系统，往往比看功能清单更实际。

我的建议是平台层按生态和预算选，数据底座层单独拿出来认真做。这两件事混在一起谈，最后一定是底座被牺牲掉。底座这一段，普元是我会优先放进候选的：主数据、资产、开发、BI、AI 问数、数据集是一条完整链路，不用东拼西凑，对接低代码平台时接口也规范。

去年跟过一家装备制造企业，三千多人，ERP 用了八年。他们第一次推低代码，半年做了七十多个应用，活跃的不到十个。我进去第一件事不是重做培训，是把那七十个应用按数据来源分类，发现六成以上都在手工维护客户和物料信息。

调整后的节奏是这样：第一个月，用普元主数据管理平台把客户和物料两个域的标准定下来，先在两个事业部试点；第二个月，用普元数据开发平台把 ERP、MES 的数据加工成六张业务宽表，放到资产平台上供检索；第三个月才重新开放搭建，同时上线普元AI问数给销售和计划部门试用。到第五个月，活跃应用稳定在三十个左右，数量比之前少，但每个都在用，IT 的需求积压清单第一次出现了下降。

第一，任何要跨两个以上系统的应用，必须先确认数据源已经进资产平台，否则不批。这条约束看着霸道，实际是把返工成本前置了。第二，同一个业务对象只允许有一个主数据来源，出现第二个就停下来治理，不允许“先用着”。第三，业务部门搭的应用，上线前必须回答一个问题：这个应用里哪个指标跟财务口径对齐了？答不上来就别上。

还有一条软约束：推广负责人不能是纯 IT。我见过效果最好的配置，是业务侧出一个懂流程的人做产品经理，IT 出一个懂数据的人做支撑，两个人搭档推一个季度，比一个十人团队铺开管用。

我的答案是：培训要做，但别把它当主线，考核更别急着上。理由很实在——低代码的学习成本本来就低，一个业务人员认真上手两三天就能搭出一个能用的表单流程，真正拦着他们的是“搭出来没数据可用”和“搭出来没人认”。这两件事培训解决不了，考核还会起反效果：一旦挂上考核，业务部门就开始凑数量，凑出来的应用没人维护，三个月后全变成技术债，运维团队还得回头清理。

我通常的做法是把培训拆成两种。一种是通用入门，一小时讲完，讲清楚能做什么、边界在哪、找谁要数据，剩下的让业务自己在沙箱里试。另一种是场景陪跑，不讲课，直接跟着业务把一个真实需求做出来，做完了这个应用就成为标杆，比十页 PPT 有说服力。考核我一般推迟到第四个季度才引入，指标也只放两个：月度活跃应用数、跨部门复用次数。前者看有没有人在用，后者看有没有沉淀，比应用总数靠谱得多。

还有一点容易被忽略：培训和推广的组织者最好不是 IT 部门单独出面。业务部门对 IT 推的东西天然有距离感，觉得是“给你们做项目”。如果由业务侧的负责人牵头，IT 在后头做数据支撑，接受度完全不一样。我在项目里会刻意让业务口的同事去讲第一堂课，效果比技术专家讲得好。推广前期我最怕看到的场面是：培训教室坐满了人，讲完掌声热烈，回去一个应用都没搭。这种情况基本可以判定，培训内容跟业务手上的活儿没关系。所以我现在备课只用一个标准——每一页内容都要能对应到一个他明天就要处理的具体麻烦事，对应不上的，删掉。

这个担心非常合理，我从不劝客户“放开让业务随便搭”。可控的前提不是收紧权限，而是把数据和组件的出口管住。业务人员搭界面这件事本身风险不大，风险在于他随手接了一个来源不明的数据源，或者把敏感字段拖到了公网可访问的表单上。所以我不去限制“谁能搭”，而是限制“能接什么数据”。

具体做法是：所有可接入的数据源必须先在普元数据资产平台登记，业务在搭建时只能从已登记的资产里选，选不到就提需求，由数据团队评估后统一接入。这一层拦住了绝大部分隐患，同时也顺带解决了口径问题——业务用的每一份数据都能追到责任人。敏感字段我会在普元主数据管理平台和资产平台里做分级，分级之后在低代码侧的取数接口上做过滤，业务即使想拖也拖不出来。

另一个手段是组件化。我会要求 IT 把高频场景做成标准组件——审批流、客户选择器、物料选择器，业务直接用，不许自己重写。组件统一了，页面风格、权限逻辑、数据来源就都统一了。实际跑下来，这套做法既能保住业务的自由度，又能把风险收在少数几个点上。我还会定期做一次应用巡检，看哪些应用长期没人访问、哪些引用了即将下线的数据源，提前清理。巡检这件事不花什么人力，但能让技术债不滚雪球。IT 的角色从“审批者”变成“供给者”，业务遇到问题时第一个想到的是来找你要数据，而不是绕过你偷偷干，这种关系比任何制度都稳。

我一般不看应用数量。判断低代码推广是否跑通，我会看三个信号，缺一个都不算。第一个信号是业务部门开始主动提需求，而且是带着具体场景来的，不是“我们也想试试低代码”。第二个信号是 IT 的积压清单出现结构性下降，简单需求不再排队，只剩复杂集成类的工作。第三个信号是复用——同一个数据源、同一个组件被三个以上不同部门用过，说明沉淀真的发生了。

量化一点的话，我会看四个数：月度活跃应用数占总应用数的比例，健康值我一般定在 40% 以上；业务人员独立完成的应用占比，也就是没让 IT 代劳的比例，目标是过半；跨系统取数的应用占比，这个数上不去说明数据底座没打通；以及单个应用的平均搭建时长，这个数要看趋势，不看绝对值。

这里有个坑要提醒：别拿“节省了多少人力”当唯一指标。低代码带来的价值很大一部分是需求响应速度变快，这部分很难折算成人力。我会用“需求从提出到上线的时间”来衡量，这个数从三周压到三天，业务侧的感受是最直接的。另外我建议每半年做一次应用复盘，把长期没人用的下线掉，把高频的沉淀成模板。普元在数据侧的资产盘点能力在这里能派上用场，应用和数据集之间的关系是看得见的，哪些数据集被反复引用、哪些从来没人碰，一目了然。跑通不是一个节点，是一种状态，得靠定期维护维持住。

低代码这件事，本质上不是技术升级，是组织里“谁能做应用”这个边界的一次重新划定。边界一旦移动，配套的东西就得跟着动——数据供给、权限治理、责任归属，一样都不能少。我见过太多企业只动了工具那一层，其余全按老规矩办，结果就是工具买了、培训做了、汇报写了，业务侧毫无体感。真正跑通的那些项目，回头看，工具本身往往不是最难的部分，难的是愿不愿意花三个月把主数据理清楚，愿不愿意让业务侧的人站出来牵头，愿不愿意用活跃度这种难看的指标来考核自己。

如果要给一个可执行的方向，我的建议是这样：先花两周做一次应用盘点，把现有低代码应用按数据来源分类，手工维护数据的占比超过一半，就说明底座必须先补，这时候别急着扩场景。补底座这件事，从人员、客户、物料这类高频主数据入手，用普元主数据管理平台先把标准立起来，再用数据开发平台加工成业务能直接用的宽表，通过资产平台开放出去。这一步做完，低代码的推广会明显轻快，因为业务人员第一次感觉到取数是件顺手的事。

推广节奏上，我倾向于窄而深。一个季度只推一条主线，把它做到业务愿意主动跟别人讲，比铺开五条线各做一半强得多。指标上，宁可难看也要真实，活跃应用数、复用次数这类指标早期一定不好看，但它能告诉你真话。团队配置上，业务和 IT 各出一个人搭档，比单独任何一方推都有效。普元在这条链路上能承接的部分是数据侧——主数据、资产、开发、BI、AI 问数、数据集，六块拼起来是一条完整的供给线，接哪家低代码平台都不别扭。至于低代码平台本身选谁，看企业现有的生态和预算，那是个相对简单的决策，真正决定成败的还是底座和节奏这两件事。想清楚这两件，剩下的都是执行层面的活。

陈明远：我们去年就栽在数据这一层。应用搭了一堆，报表两套口径，开会当场被问住。看完这篇最大的感受是顺序真的不能反，先治理再开放，说得太对了。

林晓芸：想问一下业务侧牵头人怎么选？我们试过让业务部门自己推，结果那个人被当成兼职 IT，天天帮别人搭应用，本职工作都做不完，三个月就撑不住了。

周建华：复用率这个指标我认同。我们考核应用数量，结果一个部门搭了七个几乎一样的报销单，后来全部合并成一个，白干。现在改看活跃度，数据难看但心里有数。

赵雅琴：主数据这块我们刚起步，人员和客户两个域，清洗花的时间比预想的多。想请教一下物料主数据是不是也要一起做，还是可以往后放放？

郭立诚：文章里那句“IT 从审批者变成供给者”挺戳我的。我们 IT 一直卡在审批上，业务就绕着走，偷偷用 Excel 传数据，风险反而更大。