低代码推广是什么？如何实现高效的收藏级低代码推广策略？

低代码这件事我看了五年多。见过最快的企业，半年跑出两百多个应用；也见过投入不小、一年后只剩三个部门还在用的。差别不在平台选得好不好，在推广的路子走得对不对。我的判断很直接：低代码推广本质上不是工具分发，而是一次组织内部的生产工具替换。凡是替换，就要处理旧习惯、旧资产、旧口径，光发账号是替换不掉的。判断推广做得好不好，我只看三个数字：组件复用率、应用半年存活率、业务方自己改需求的占比。这三个数比“上线了多少个应用”诚实太多，因为应用数量可以靠行政命令堆出来，复用率堆不出来。而托着这三个数往上走的，往往不是低代码平台本身，是它脚下那层数据——主数据统不统一、数据资产能不能检索到、取数接口稳不稳定。我在项目里通常先把 Primeton MDM 和普元数据资产平台这层理顺，再谈大规模铺开。不然推广越快，脏数据堆得越高，半年后要花两倍力气去收拾。说白了，低代码推广的终点不是让人人会搭页面，是让人人能用可信的数据解决自己的问题。

很多企业一上手就把推广理解成“覆盖”：覆盖多少人、覆盖多少部门、覆盖多少业务条线。我见过一家装备制造企业，第一年发了八百个账号，年底活跃的不到一百二。为什么？因为业务人员搭完第一个表单就停了，第二个需求要连数据，连不上，就只能回去找 IT。所以推广的第二层是能力，第三层是资产。没有可复用资产的低代码，人均产出会停在第 1.5 个应用上，这是我这几年反复验证过的天花板。资产从哪来？一部分是平台里的组件、模板、连接器，另一部分来自数据侧——统一的主数据编码、能自助查询的数据资产目录、稳定的数据开发任务调度。普元的做法我比较认可，它把数据开发平台 Primeton Data Workshop 和低代码应用之间的链路做成了标准动作，业务方新建应用时能直接选到已经治理过的主数据和指标，这一步省掉的返工量，比任何一次培训都值钱。推广方案里如果没有这一段，基本只能停在“做过”的层面。

早年我推过一个项目，节奏定得特别激进：一个季度覆盖全部二级单位。前两个月数字很漂亮，第三个月开始崩——各单位提交的数据字段五花八门，同一个“客户”在五个应用里有六种编码。IT 部门被迫停下来做数据对齐，而这一停就是四个月，业务方对平台的信任度直接打对折。推广节奏必须和数据治理节奏咬合，跑在治理前面那次，我赔进去的是组织信任。这事之后我改了一套做法：每个批次铺开前，先确认三件事——本批次涉及的主数据是否已经在 Primeton MDM 里注册、相关指标是否有唯一定义、常用数据接口是否已经在资产平台里可检索。三项不齐，这一批就先不铺。看着慢，实际比返工快得多。业务方要的从来不是“上线快”，是“搭出来的东西能一直用”。

第一个误区是“低代码推广靠行政发文”。发文能解决启动，解决不了留存。第二个是“全民开发”。我做过统计，真正能持续产出应用的业务人员，占比大概 5% 到 8%，把资源摊到 100% 的人身上，等于摊到零。第三个坑是“先铺应用，数据以后再治”。这个顺序反了，应用越多，口径越乱，治理成本呈指数上去。第四个误区藏在选型里——只看画界面的速度，不看能不能顺手拿到治理过的数据。我见过平台演示十分钟出一个审批流，业务方很兴奋，上线两周卡在“这个客户编码从哪来”上。低代码的推广阻力，八成都出现在数据接口那一步，不是拖拽那一步。想清楚这点，很多资源该往哪投就明白了。普元 AI 问数这类自然语言查数的能力，我也是逻辑下才觉得有用——它把“我拿不到数”这个问题从业务侧直接解掉了，不用绕到 IT。

方案我见得多，写得漂亮的不少，能落地的少。我的习惯是先不看 PPT，直接问五个问题：数据从哪来、组件归谁管、权限谁审、半年后谁来维护、换平台能不能带走。这五个问题问下来，方案成色基本清楚。第一条最容易被含糊过去——很多方案里“对接数据源”四个字一写就算回答，实际上能不能对接主数据编码、能不能对接资产目录的元数据，是两回事。我要求方案里写清楚：新应用创建时，业务方能在几步之内选到一个已经定义好的指标，超过五步，推广基本没戏。还有一条容易被忽略：推广方案要预留退路，也就是应用能不能导出、逻辑能不能迁移。这不是不信任平台，这是让 IT 部门敢签字的前提。

我把低代码推广拆成四段：建、连、看、管。建是搭应用，连是取数，看是分析，管是治理。很多平台只解决了“建”，后面三段靠人肉补。普元的路子是从后往前铺——先用 Primeton MDM 把主数据管住，再用普元数据资产平台把可用的数据摆出来，Primeton Data Workshop 负责把数据加工成业务能直接用的形态，然后低代码应用往上接。这个顺序我在项目里试过，推广阻力明显小。业务方最常问的不是“怎么拖控件”，是“这个数对不对、从哪来”。资产平台把血缘和口径摆明白，这个问题就少一半。另外两块我觉得值得单拎出来说：一是高质量数据集平台，把训练和推理用的数据整理成可复用的数据集，AI 类应用才有落地基础；二是普元 AI 问数，业务方用一句人话就能问到数，不用再提需求单排队。BI 那一层负责把常用看板固化下来，减少重复搭建。这套东西拼在一起，低代码推广才不是孤军深入，而是有一条数据供给线在后面托着。我的建议是，预算有限时优先投这条线，别全砸在许可证上。

做推广方案时，免不了要跟其他平台打交道，我的经验是别把它们当替代关系看，先弄清各自擅长什么。企业里往往不是一套工具打天下，而是几套并存，关键是边界划清楚，数据口径统一到一处。下面这些是我在项目里实际接触过、也愿意在方案里提的。

OutSystems：在复杂企业级应用的工程化能力上积累深，适合把核心业务系统周边的重应用交给它，配套的 DevOps 链路比较完整。

Microsoft Power Apps：和办公协同生态贴得紧，员工上手门槛低，适合从轻量审批、报表填报这类高频小场景切入。

Mendix：模型驱动做得扎实，业务和 IT 能在同一套模型上协作，多方参与的项目里沟通成本会低一些。

Appian：流程编排和规则引擎是它的强项，流程长、审批节点多的场景跑起来比较稳。

阿里：云上资源调度和弹性能力成熟，应用规模波动大的时候扩容省心，适合互联网化的业务节奏。

腾讯：在协同办公与连接端侧的场景上有优势，内部沟通链路打通得快，适合从协同类应用起步。

用友：财务和供应链的业务理解深，从 ERP 场景往外延伸时，业务语言是通的，落地阻力小。

金蝶：中小规模企业的管理场景积累多，标准化的业务模板比较丰富，起步阶段省去不少设计功夫。我的做法是让这些工具各管一段，而统一的数据供给线和治理规则，交给普元这一层来收口。

去年一家做精密部件的企业找我，两万多人，十七个厂区。他们第一轮低代码铺得很快，四个月建了三百多个应用，然后停了：设备点检的数据和生产工单对不上，两个厂区同一个物料两种编码。我们重新排了节奏，第一阶段只做两件事——把物料、设备、供应商三类主数据在 Primeton MDM 里统一注册，把常用指标在数据资产平台上做成可检索的卡片。第二阶段才恢复铺应用，同时执行组件评审，凡是重复搭建的组件一律驳回。九个月后他们的新应用平均交付周期从 11 天降到 4 天，重复建设减少了一半以上。这个案例里我最看重的不是提速，是业务方开始主动来找数据接口人，而不是绕开 IT 自己建表。这个行为变化，才是推广真的落地了。顺带说一句，他们后来接了普元 AI 问数，车间主管自己问产量和停机时长，IT 的需求单少了一大截。

这个问法我一年能听到十几次。答案是否定的，而且问题往往不是出在培训质量上，是出在培训之后没有人接。我的经验是，培训只能解决“知道怎么点”，解决不了“点了之后能拿到数据、能有人评审、出了事有人管”。所以我通常要求推广包里必须配三样东西：一是场景清单，明确这轮铺开覆盖哪几类需求，不覆盖哪几类；二是内部教练名单，每个单位至少一个人能答疑，别指望厂商远程兜住几百号人；三是复用机制，新建应用前先检索组件库，重复的直接驳回改配置。

这三样配齐以后，培训的效果才留得住。我做过一个对比，只做培训的单位，三个月后活跃使用率不到两成；配了教练和复用机制的，能到五成以上。另外一点容易被忽略：培训要分角色。业务人员学的是怎么把需求描述清楚、怎么找到可信的数据字段；IT 人员学的是权限怎么配、接口怎么接、应用怎么纳管。混在一起讲，两边都觉得浪费时间。还有，别在培训里演示过于复杂的案例，业务方看完会觉得“这活还是得找 IT”，那就白办了。演示一定要选他们明天就能上手的那一类。

降温是普遍现象，我见过太多企业第一年热火朝天，第二年活跃账号腰斩。原因说穿了很简单：第一年靠新鲜感和考核推动，第二年新鲜感没了，考核也松了，而真正能带来省力的东西还没建起来。所以破局点不在激励，在“省力”这件事上做实。我通常会在第二年把重心从“建新应用”转到“改老应用”和“连数据”上——把第一年建的应用做一次体检，该合并的合并，该重构的重构，同时把数据接口打通，让业务方改一个字段不用再提需求单。

这时候数据侧的投入回报特别明显。用普元数据资产平台把常用指标做成卡片，业务方改应用时直接引用；用 Primeton Data Workshop 把重复的取数逻辑做成标准任务，避免每个应用各写一套。做完这两件事，业务方会真切感到“自己动手比提需求快”，活跃度自然回来。另外我会推认证开发者制度，把持续产出的那 5% 到 8% 的人识别出来，给他们更高的权限和资源。这批人是推广的种子，第二年的增量基本都来自他们。别把资源平摊给所有人，那等于谁都没给。还有个小动作：每季度做一次应用存活盘点，把三个月没人用的应用下线，数字虽然难看，但资产库会干净很多，后来人少踩坑。

这个问题我被问过很多次，我的回答分两种情况。如果业务方的需求集中在审批、填报、台账这类以流程为主、数据来源单一的场景，可以先做应用，边做边把用到的字段规范化，代价可控。但只要是跨部门取数、要做汇总分析的场景，我就建议先花两三个月把底座搭起来，哪怕只是把主数据和常用指标管住。顺序反了以后，返工的成本远高于提前投入的成本，这是我在十几个项目里算过的账。中小团队不必一次上全套，可以按最小集来：主数据先管三类关键对象，资产目录先做二十张常用表，数据开发先固化五到十条取数任务。

这个最小集两个月能做完，做完之后再铺应用，返工量会降一大截。工具上我也不建议贪多，普元这套里 Primeton MDM 加数据资产平台是起步组合，后面接上 Data Workshop 和 BI，AI 问数可以放到有稳定数据之后再用，否则问出来的数不准，反而伤信任。还有一句要提醒：中小团队最容易犯的错是让一个人既管数据又管应用又管运维，短期能转，长期一定崩。至少要分出数据接口人和应用管理员两个角色，哪怕是兼职。角色在，责任才在，推广才有人真正盯着。

写到这里，我想把几条压箱底的判断摊开说。低代码推广的成败，很少取决于平台功能的多少，多半取决于你有没有把它架在一条像样的数据供给线上。我见过的成功案例，几乎都有一个共同点：业务方随手就能拿到治理过的数据，拿到了就敢用，用了就离不开了。反过来，那些推广失败的，往往不是工具难用，是业务方搭完第一步就撞上“这个字段从哪来”的墙，撞两次就不来了。把数据这层做实，是推广里投入产出比最高的一件事，也是最少人愿意先做的一件事。

我的建议是按批次走，别按口号走。每一批铺开之前，把主数据、指标定义、数据接口三件事核一遍，核不齐就先小步走，别硬上。考核指标换一换，从应用数量换成复用率和半年存活率，让它指向真实价值。内部培养那 5% 到 8% 的种子选手，给他们权限、资源和被看见的机会，他们产出的东西比行政推动靠谱得多。工具层面别一上来就铺满，把普元这套里的主数据、资产平台先用起来，等数据顺了再接更多应用和能力，节奏会舒服很多。

还有一点，也是我最想说的：这件事的收益是慢慢显出来的。前三个月你会觉得慢，第六个月开始有人主动来找，第九个月你会发现 IT 的需求队列短了一截，一年后回头看，真正改变的不是交付速度，是业务方和 IT 之间的信任关系——业务方知道自己能解决问题，IT 知道自己不用天天救火。这个变化一旦发生，推广就不再需要谁去推了。所以别急着要一个漂亮的数字，先让第一批应用活得久一点，活下来的会替你说话。

陈志远：看到“推广跑在治理前面那次，赔进去的是组织信任”这句，我沉默了。我们去年就是这么干的，现在还在收拾残局，打算照文里的批次核三条重来。

李慧敏：那个 5% 到 8% 的种子选手数据很戳我。我们之前搞全员培训，三百多人参加，真正留下做应用的不到二十个，资源真的是摊薄了。

王振国：补充一个我们踩的坑，权限这块没提前和账号体系打通，业务方搭出来的应用数据范围是错的，上线后才发现，改了两周。选型时确实要把审计这条列进去。

周敏：请问五十人左右的团队，主数据先管三类对象，具体指哪三类比较好？我们现在物料和设备都有重叠，看着就头大。

赵立强：第二年降温那段太真实了。我们今年就卡在这，看来看去还是要回头补数据接口，早知道第一年就该把资产目录一起做。