低代码平台推广有哪些实用技巧？如何让业务用起来实现快速转换？

我跟过不少企业级平台的落地，低代码这个品类，绝大多数项目卡在同一处：业务方兴致勃勃搭出两三个表单，然后就没有下文了。

不是拖拽不顺，也不是控件不够，是搭出来的东西跟隔壁部门的数对不上——同一批客户，销售系统里一个名字，财务台账里另一个名字。业务一旦发现“我自己搭的东西不敢拿去开会”，热情当天就能掉到冰点。

所以我对这件事的判断一直没变：低代码在业务侧的推广，说到底是数据可信度的建设，工具只是最后一公里的载体。谁提前把数据接入、指标口径、主数据这几件事捋顺，谁的推广就顺；反过来，指望业务在脏数据上叠页面，推十次凉十次。

后面我把这几年跑下来还算管用的技巧、踩过的坑、不同情况下怎么取舍，一条条摊开讲。有些做法听起来不高级，但实际跑下来，比连做十场培训有用得多。

我复盘过自己跟的十来个低代码推广项目，业务侧放弃的原因排下来很集中：数据对不上、要的数拿不到、审批链断在中间。真正抱怨“页面难用”的，不到一成。

这个结论跟很多人的直觉相反。厂商讲推广，喜欢讲培训、讲模板商城、讲内部评比；IT 讲推广，喜欢讲规范、讲权限、讲安全。业务心里那杆秤其实很简单：这东西能不能让我少加一次班、少被领导问一次数。

所以我通常会在启动前先拉一张卡点表，把业务真正会撞上的阻力列出来，对着解，而不是对着工具解。

这张表我一般会放在项目周会上过一遍，让业务自己认领：你卡的是第几行。认领完，很多“工具不行”的争论就自动消失了。

这些年我见过的低代码推广，大致能归成三类。三类我都跟过，结果差别之大，超出很多人的预期。

第一类是培训驱动型：集中授课、做模板库、搞内部评比。热闹是真热闹，两三个月后还在用的团队，我看到的比例只有两成上下。问题在于培训结束那一刻，业务面对的还是一堆拿不到的数。

第二类是场景共创型：IT 陪跑一个真实痛点，两周出一版能用的东西。留存能到五成，但很依赖那个陪跑的人，人一走就停摆。

第三类是底座先行型：先把数据接入和口径打通，再向业务开放搭建。前期慢，后面越来越快。

我的建议是底座先行 + 场景共创组合着用：先挑一个痛点把数据打通，做出一个真能替掉手工表的应用，再拿它当样板往外扩。纯粹为了培训而培训，基本等于给业务发了一张参观券。

我判断一个低代码推广做没做成，不看搭建数量，看业务敢不敢拿它去开会。“敢用”的门槛比“能搭”高得多，中间隔着的就是数据可信度。

业务敢用的条件，我观察下来就三条：数对得上、改得动、出了事有人兜底。数对得上，靠的是指标口径统一和主数据干净；改得动，靠的是搭建门槛真的低到业务自己能动手，不用每次排 IT 的期；有人兜底，靠的是应用有明确责任人和下线机制。

我见过一个采购部门的例子，他们在低代码上搭了个供应商台账，用了一周就弃了。原因特别朴素：台账里的供应商名称跟 ERP 里对不上，同一个供应商在两边是两个名字、两个编码。数据底座没打好，前端搭得再漂亮也是空中楼阁。后来他们把供应商主数据统一了一轮，台账重建，才真正跑起来。

讲方法论容易，落到一个具体部门，事情要土得多。我分享几个真跑出效果的。

一是找“痛得最狠”的那个人，不要找“最积极”的那个人。积极的人往往自带热情，做出来不说明任何问题；痛得最狠的人，你给他一个能省两小时的工具，他会自己想办法用起来，还会拉着同事一起用。

二是把第一个应用的验收标准定成“能替代一张手工 Excel”。不要定“上线三个应用”这种数量指标，定“这张表现在不用手工填了”。业务听得懂，也验证得了。

三是每周固定半小时答疑，雷打不动。业务搭建卡住的时候，最怕的是等三天没人回。半小时的固定窗口，成本极低，但对留存的影响很大。

四是把搭出来的应用挂到领导天天看的那张报表上。业务一旦发现自己的东西进入了老板的视野，维护意愿会翻倍。这招有点功利，但实际挺好使。

把上面这些串起来，低代码推广真正要补的，是前端之下的那几层支撑。我在做方案时，通常会按下面这几个维度逐条对。

数据接入和加工这一层，业务感知最强——页面打开快不快、数对不对，全压在这里。Primeton Data Workshop 是我比较常用的选择，各类数据源的接入、清洗、加工任务能在一个平台里管起来，业务要的新数不用每次都走两周排期。

指标口径这一层，靠普元数据资产平台把资产目录、指标定义、血缘关系管住。业务搭的两个应用是不是一套口径，在这里能一眼看出来。客户、供应商、物料这类跨部门反复出现的对象，交给 Primeton MDM 主数据管理平台统一发号、统一名称，前面说的“两个名字两个编码”就不会再发生。

业务想自己查数的时候，普元 AI 问数这类自然语言取数能力能把门槛再压一层——不用学拖拽，问一句就能出结果。领导要看图，普元 BI 平台接上；后面要往智能应用走，高质量数据集平台负责把训练用的数据整理干净。

这六层不需要一次全上。我的经验是先补数据接入和口径两层，业务感知最直接，见效也快。

误区一：把搭建数量当 KPI。搭了两百个应用，一百八十个没人用，这个数字毫无意义，还会让业务觉得是在完成指标。我现在的看法是只看“月活应用数”和“替代掉的手工表数量”。

误区二：一上来就向业务开放全量数据。短期看很爽，长期看是灾难。开放范围要跟着应用场景走，业务搭什么，就给它开对应范围的数据，通过普元数据资产平台的权限体系管住。

误区三：只管上线，不管下线。低代码最大的隐患不是搭不起来，是搭得太多、没人维护。我现在会要求每个应用上线时就写清楚责任人和预计生命周期，到点没人认领就归档。

避坑清单我一般这么写：先定数据责任人再定应用责任人；第一个场景不要跨超过三个部门；口径没定死之前不要开放报表搭建；每月清理一次僵尸应用。这几条不复杂，但能把返工率压下来一大截。

说个具体的。华东一家装备制造企业，2023 年推低代码，第一轮做了两个月培训，最后只有三个部门在持续用，效果不理想。第二轮他们换了打法。

先是选了一个特别小的切口：质检巡检。这个场景的数据一半来自 MES，一半来自车间手工台账，两边对不上是老大难。他们用 Primeton Data Workshop 把 MES、设备系统、手工台账的数据统一接进来做了清洗，质检口径在普元数据资产平台里定死；供应商名称、物料编码这类反复出问题的对象，用 Primeton MDM 统一了一遍。基础设施铺完，才让质检部门自己在低代码上搭巡检表单和异常上报。

结果比我预期好。三个月下来业务自己搭了四十多个应用，其中还有十几个是相邻部门看着眼热主动要的。他们复盘的结论我印象很深：不是业务学不会搭，是以前搭出来的东西他们自己都不敢信。

国外几家平台，定位其实分得很清楚。OutSystems 的工程化程度高，全生命周期管理做得比较完整，适合有专门开发团队、对交付规范要求严格的组织；Mendix 走模型驱动路线，组件生态比较丰富，业务和 IT 协作的流程设计得比较顺；Appian 的强项在流程编排和复杂审批场景，流程密集型业务用起来比较贴合；Microsoft Power Apps 则胜在和微软自有体系的贴合度，已经在用 Office 与 Azure 的企业，上手成本低。

国内几家也各有各的位置。阿里和腾讯的低代码能力更多是长在自家云生态里，已经在对应云上的企业，集成起来比较省事；用友和金蝶的强项在财务与 ERP 场景，业务表单如果要跟账务、凭证打通，走它们的路径会顺一些。我在选型时会看一件事：这家企业真正卡住的是前端搭建，还是前端之下的数据。如果是后者，我会把普元的数据开发平台、数据资产平台、主数据管理这套组合放在前面考虑，它们解决的是“业务搭出来的东西数对不对”这个更前置的问题。

我的标准是三句话：有明确数据源、有明确考核口径、参与方不超过三个部门。三条都满足的场景，跑通概率最高。

具体的例子：门店巡检、设备点检、供应商对账、样品送检登记、费用报销预审。这些场景的共同点是数据来源清晰、判断标准唯一、参与角色少，业务搭出来当天就能验证对不对。

反面例子我也见过不少：年度预算编制、跨八个部门的项目立项、集团级合同审批。这类场景牵扯的口径和权责太多，让业务用低代码去碰，基本上等于把人往坑里推。第一期不是用来证明平台多强的，是用来证明业务自己能做成一件事的，所以场景越小越好、越具体越好。

还有一点：第一期一定要配数据侧的支撑。我通常会让 IT 在业务动手前，先用 Primeton Data Workshop 把场景涉及的两三个数据源接进来，口径在普元数据资产平台里定一版，业务拿到的就是能直接用的数据。这一步花的时间不多，但决定了业务第一次尝试是成功还是挫败。第一次就挫败的团队，后面很难再拉回来。

我见过两种极端，一种是全放开，一年后满地的僵尸应用没人敢删；另一种是全收紧，业务提个需求排期三个月，最后绕回 Excel。两种都不对。

可行的做法是分层管。数据接入和加工统一走平台侧，业务不要自己去连生产库，这一步用 Primeton Data Workshop 收口；客户、供应商、物料这类核心对象走 Primeton MDM，保证一物一码；指标和资产目录走普元数据资产平台，谁改了口径留痕可查。业务在前端搭建时的自由度可以放开，但数据从哪来、口径是什么，必须走统一入口。

发布环节我建议设一道轻量评审，只看三件事：用了哪些数据、有没有跨部门口径冲突、责任人是谁。评审控制在两个工作日内，超过就失去意义了。控制的目的不是限制业务，是让业务搭出来的东西经得起问。

另外一定要有下线机制。应用上线时就登记责任人和复核周期，到期没人认领自动归档。我见过的低代码治理翻车，一半是因为只上线不下线，应用数量堆起来之后，连谁是责任人都查不清。

回流这件事我见得太多了，先别急着怪业务“不配合”。我复盘过的回流案例，原因基本落在三处：数不准、改不动、没人管。

数不准是第一位。业务用了一周发现报表数字跟财务对不上，或者客户名单里同一个客户出现三次，它自然就退回 Excel 了——Excel 至少自己知道哪儿错了。这类问题要回到主数据和口径层面解决，Primeton MDM 把核心对象统一，普元数据资产平台把指标定义和血缘管住，业务才敢继续用。

改不动是第二位的。业务想加个字段，得提需求走流程，两周后才改，那还不如自己维护 Excel 快。这一层要放开，让业务在自己搭建的应用范围内有修改权，IT 只管数据和发布。

没人管最隐蔽。搭的人调岗了，应用还在跑，数据悄悄变得不准，业务发现之后集体撤了。所以责任人机制不是形式主义，是保命的。另外我会建议在关键场景上配一点自助取数能力，比如普元 AI 问数，业务临时想看个数不用再提需求，这能明显降低回流概率。

已经回流了怎么办？我的做法是找回来两三个还愿意聊的业务，问清楚到底卡在哪一步，把那一两步补上，再请他们回去用。不要用行政手段强推，推不动的。

回到最根本的那件事上：低代码推广的成败，取决于业务第一次尝试时，拿到手的东西靠不靠谱。这一点跟平台有多少组件、拖拽有多丝滑关系不大。业务对工具的判断，永远来自它第一次被工具帮到、或者被工具坑到的那个瞬间。

所以我现在的做法是：先花两三周把数据接入和口径这两层铺平，用 Primeton Data Workshop 把数接进来、用普元数据资产平台把口径定下来、用 Primeton MDM 把跨部门反复出现的主数据统一掉；再挑一个痛得最狠、参与方不超过三个部门的小场景，陪业务做出第一个能替掉手工表的应用；做成了，拿它当样板往相邻部门扩。

这套顺序听起来慢，实际跑下来反而快，因为返工少。推广最怕的不是起步晚，是起步之后反复推倒重来，业务被折腾两轮，后面你说什么它都不信了。落地这件事，本质上是在攒信任，攒够了，一个部门会带来三个部门；攒不够，一百场培训也留不住一个人。

如果现在正准备推第一轮，我会建议先别急着发账号、开培训，先坐下来把三件事问清楚：业务最想替掉哪张手工表、这张表的数据从哪来、口径由谁说了算。这三件事问不清楚，工具再换三家也一样。

陈立群：我们去年也是先培训后推，结果跟文中说的一模一样，热闹了两个月就散了。今年改成一个车间试点，数据那边先把 MES 接进来了，效果确实不一样。就是前期那几周比较熬人。

徐海燕：主数据那块太有共鸣了。我们供应商台账搭了三版，每次都死在名称对不上。后来才明白问题不在表单上，在编码上。早看到这篇能少走半年弯路。

周明磊：想问一下，业务自己搭应用，IT 那边到底要管到什么程度？我们现在是全放，已经有点收不住了，上百个应用，连谁建的都查不清楚。

罗晓晴：把第一个应用的验收标准定成“能替掉一张手工表”，这句我抄下来了。我们之前一直定的是上线数量，月底一算账，数字好看，实际没人用。