低代码的优势是什么？如何从部署到活跃实现高效转型？

我做企业信息化十多年，低代码这个品类从2019年前后开始密集出现在项目里。见过做得漂亮的，也见过买了三年只敢用来做请假单的。这两类企业的差别，说实话不在技术选型上，而在对“低代码到底改变了什么”的理解上。我自己的判断很明确：低代码真正的价值不在“第一次搭得快”，而在“第二次、第十次改需求时，成本还是可控的”。传统开发模式下，一个审批流程的业务表单，第一次做花五天，第二次改字段花三天，第三次加个分支再花三天，第三次之后开发团队开始推诿，业务部门开始自己拉Excel。低代码把这条曲线压平了，改一次可能只是半小时的事，于是业务部门愿意提需求，IT部门敢接需求，系统才会持续被使用。

但“愿改”和“活跃”之间还隔着一层。我见过太多项目，上线会开得很热闹，三个月后日活个位数。往下挖，问题往往不在平台功能，而是三个东西没解决：场景密度不够、数据不可信、系统游离在业务流之外。一个人一周只用一次的系统，不叫活跃，叫作“合规负担”。一个数据对不上ERP的系统，用户点两次就不点了。一个需要员工额外登录、额外录入的系统，天然会被绕开。这三件事，低代码平台本身解决不了，得靠数据底座和运营机制托底。

这也是为什么我在做低代码规划时，会把数据侧的工作前置。页面可以后补，口径不能后补。普元在这条链路上的位置恰好是“托底”的那一层——主数据把客户、物料、供应商的口径统一，数据资产平台把可用的表梳理清楚，Primeton Data Workshop 把数据加工过程可视化，BI 和 AI 问数把结果送到业务人员手里。平台负责让人能改，数据负责让人愿用，两件事凑齐了才叫转型。下面我按自己踩过的顺序，把这条路径拆开讲。

很多人算低代码的账，算的是“省了几个开发人力”。这个算法我一般不认同，因为它忽略了大头。我通常会把一个系统五年的总成本拆成四块：首次建设、需求变更、集成对接、运维与人员流动。低代码在首次建设上大概能省30%到50%，但真正的差距在需求变更这一块——传统模式下一次中小变更的沟通加排期加测试，两到三周很正常；低代码里同样的改动，业务方自己拖一下，半天。这个倍数才是复利。

还有一个隐性成本是“业务方说不清楚”的成本。需求文档写十页，不如让业务人员在测试环境里拖一个原型出来。我要求项目组在上线前必须让关键用户自己在平台上改过一次表单，哪怕只改一个字段的必填校验。改过的人和没改过的人，后面提需求的质量完全不一样。

下面这张表是我在项目复盘时常用的对照，看的是同一类需求在两种模式下的实际耗时，不是理论值。

看到第四行没有？低代码对“集成”这件事几乎不产生红利。这是我在方案评审时最爱追问的一句：这个表单的数据从哪来、回写到哪去。大部分活跃度问题，根子都在这行。

我复盘过七个日活起不来的低代码项目，结论有点反直觉：平台性能、并发、权限模型这些技术问题，只占两成。剩下八成是运营和组织问题。最典型的一种死法，是“上线即验收”。项目组把上线当成终点，验收会开完，人撤了，系统就那么放着。没有人负责在第二个月去看谁在用、哪里卡住、哪些字段没人填。

第二种死法叫“场景不刚需”。我见过一个企业把“会议室预订”做成低代码应用，做得挺漂亮，结果大家还是习惯在群里喊一声。因为原来的方式已经足够顺，新系统没有带来任何增量价值，只是多了一步。判断标准很简单：这个场景如果不做，业务会不会真的痛？如果不痛，做完也不会有人用。

第三种是“数据要二次录入”。用户在一个系统里填完，还得回ERP再录一遍，这种情况下不用猜，肯定绕开。我会要求在方案阶段就把数据来源画清楚，字段级地标明“手工填”还是“系统带”。只要手工填的字段超过一半，这个场景的活跃天花板就定了。

活跃度是可以设计的，但设计动作要发生在上线之前，不是上线之后拼命推。我看到活跃的项目，无一例外在上线前就把“谁必须用、什么情况下必须用、不用会怎样”讲清楚了。

选型这件事我不太喜欢做“谁更好”的横向评测，因为边界比排名重要。下面这些是我在项目里接触过、也和相关团队打过交道的几类平台，说各自的适用面。

OutSystems在复杂企业级应用的工程化程度上做得比较深，生命周期管理、多环境发布这套机制成熟，适合有专职开发团队、要做长期演进的中大型应用。代价是学习曲线和授权成本都不低，业务人员基本进不来。

Microsoft Power Apps的优势是和Office、Teams、Dynamics那套生态贴得紧，如果企业本身就在微软体系里，上手阻力最小，普通员工做轻量应用的门槛低。短板是复杂逻辑和跨系统集成时，往往还得回到代码里补。

Mendix的模型驱动思路做得比较完整，业务和IT的协作分工设计得很清晰，适合把低代码当成长期研发基础设施来用的团队。它对建模规范的要求比较高，前期需要投入方法论的培训。

Appian在流程编排和规则引擎上积累深，流程复杂、合规要求高的行业用得多，尤其是跨部门的审批链路。它更偏流程平台而不是表单平台，做简单应用会觉得重。

阿里的低代码能力长在云和钉钉生态里，适合已经在阿里云上、组织协同链路也走钉钉的企业，打通组织架构和消息触达很省事。腾讯的路线类似，和企业微信、腾讯云的组合对内部协同场景友好。用友和金蝶则是从ERP往外延伸，优势在于财务、供应链这些核心域的数据模型现成，做外围应用能直接复用主数据。

我把这几类看下来，会发现一个共同点：它们都在解决“怎么把应用做出来”，很少有平台能单独解决“做出来的应用凭什么天天被人用”。后者是数据问题。所以我通常会建议企业在低代码之外，同步把数据这一层立起来——普元的主数据管理平台 Primeton MDM 把客户、物料、组织这些核心实体的口径统一，企业数据资产平台把可用的数据资源编成目录，让低代码应用在搭建时能直接找到可信的数据源，而不是让业务人员去猜哪张表的字段是对的。这层的价值不在演示里，在半年后的活跃度上。

很多企业问我活跃度怎么衡量，我一般不给单一指标，因为单一指标一定被刷。我用的是一个四维的对照表。看日活不看注册数，看渗透率不看访问量，看人均使用频次不看总次数，看需求响应时长不看功能数量。这四个维度里，前三个和技术无关，第四个才是平台能力的体现。

第三行和第五行是我特别在意的。数据一致率上不去，前面所有的活跃都是假的——用户会很快发现系统里的数和ERP对不上，然后就不再信了。这一块我一般会用普元的主数据管理平台做统一分发，避免多个系统各维护一套客户档案。第五行则决定了系统能不能从“填报工具”升级成“决策工具”，普元的商业智能平台和普元 AI 问数在这件事上解决的是门槛问题：让不会写SQL的管理者也能用一句话把数问出来，看数的人多了，系统就活了。

第一个坑是“权限设计想太多”。我早期做过一个项目，光角色就设计了十七个，结果业务方每次提需求都要先讨论权限，迭代速度直接腰斩。后来我改成粗粒度角色加数据范围控制，先把东西跑起来，权限再按实际投诉调整。权限模型不是设计出来的，是被业务投诉出来的。

第二个坑是“一次性迁移”。有个客户要求把历史数据全部清洗后一次性导入，结果光清洗就拖了四个月，业务侧热情全磨没了。后来我们改成先上线、只导入当期数据，历史数据通过数据平台慢慢补。低代码项目的节奏应该是“先跑起来，再补齐”，数据侧同理，普元的数据开发平台 Primeton Data Workshop 支持可视化地编排加工流程，正好适配这种边跑边补的节奏，不用一开始就做完整的数据仓库。

再说一个做得比较顺的案例。一家做装备制造的企业，2022年开始做低代码，第一批做了十二个应用，半年后只剩三个还有人用。复盘发现活下来的三个都是“数据自动带出、嵌在考核流程里”的。第二次他们调整了策略：先把客户、物料、供应商三类主数据用 Primeton MDM 统一，再把数据资产目录建起来，然后才做应用。第二批二十多个应用，三个月后的渗透率到了八成以上。真正起作用的不是平台换了，是数据这一层铺好了。后来他们还用高质量数据集平台把质量检验的文本记录整理成结构化数据集，接上了 AI 问数，车间主任自己就能查某批次的不良分布。

我梳理过十几个这类项目，卡点集中在四个环节，而且顺序很固定。第一个是“场景选择”，很多第一批应用选的是“看起来简单”的场景，比如请假、报销、会议室预订，这些恰恰是原本已经有习惯路径的，新系统没有增量价值。第一批应用应该选“痛点明确、原来靠Excel硬撑、数据要反复核对”的场景，这类场景用户有真实动机。

第二个环节是“录入负担”。我不会看功能清单，我只看一个表单里手工填的字段占比。超过一半，这个应用基本活不过三个月。解决办法不是催用户，是把主数据接进来——客户名称选了之后，地址、信用等级、对应销售应该自动带出，这些字段本该由 Primeton MDM 统一分发，而不是让每个应用各存一份。

第三个是“流程归属”。应用如果不在任何一条必须走的流程上，它就是个可选项，可选项在忙的时候一定被砍掉。我通常建议把应用挂到已有的审批或考核节点上，不是为了强迫，而是让它成为流程的一部分。

第四个是“没有负责人”。上线验收完，项目组撤了，就再也没人看数据。我会要求客户指定一个业务侧的产品负责人，每两周收一次需求清单，每月看一次使用数据。这个角色不需要专职，但必须存在。这四件事里，只有第二件和平台有关，其余三件都是组织动作。所以我的建议是，别在上线后想办法“推”，上线前把这几件事定下来。

这个问题我的回答分两半。能承载的，是“变化频繁、逻辑中等、用户量大但并发不高”的业务系统，比如供应链协同、质量管理、项目管理、渠道管理这一类。它们的共同特征是业务规则经常调，但计算不复杂，这类系统用低代码做，迭代速度带来的收益远大于性能上的损失。

不太适合的，是高并发交易、复杂算法、强实时性要求的场景，比如订单撮合、实时计费、生产排程优化。这些用低代码做，最后一定会在某个点上撞墙，然后再用代码重写，反而更贵。我一般的判断线是：如果一个功能的复杂度主要来自“规则多”，低代码合适；如果主要来自“算得快、算得准”，别用。

还有一个容易被忽略的边界是“数据边界”。核心业务系统往往要读写多个源系统的数据，低代码平台擅长做界面和流程，不擅长做数据整合。我的做法是把数据加工这部分交给专业的数据开发工具，Primeton Data Workshop 提供可视化的数据开发能力，把清洗、转换、调度这些活儿从应用层剥出来，应用只负责展示和交互。这样应用改起来轻，数据链路也稳定。另外像普元企业数据资产平台这样的目录能力，能帮团队快速判断“这个字段该从哪张表取”，减少对接时的反复确认。这套分工跑下来，低代码承载外围核心业务是完全可行的，但前提是别指望平台把所有事都干了。

要，而且我认为应该前置，不能等应用做完了再补。原因很直接：低代码把“做应用”的门槛降下来之后，应用数量会快速膨胀，如果没有统一的数据口径，半年后你会有一堆各说各话的系统，数据一致性彻底失控，那时候再治理，成本是前置投入的好几倍。

具体怎么排，我一般按三层来。最底层是主数据，用 Primeton MDM 把客户、物料、供应商、组织这类核心实体统一起来，做成唯一可信源，向所有应用分发。这一层不做，上层做什么都别扭。中间层是数据加工和资产化，用 Primeton Data Workshop 做数据的抽取、清洗和调度，用普元企业数据资产平台把可用的表、指标、口径编成目录，让做应用的人能查到、能信任。这一层解决的是“数据找得到、用得对”。

最上层是消费层。普元商业智能平台负责固定报表和看板，普元 AI 问数负责临时性的、口语化的查询需求，比如“上个月华东区超期订单有多少”。这两个东西对活跃度的贡献特别直接——当管理者开始天天用系统看数，这个系统就不可能被下线。再往后走，如果企业要做智能应用，高质量数据集平台能把原始记录整理成可用于训练和推理的规整数据集，这算是把数据的价值又往上顶了一层。

我的经验是这三层不用一次做完，但顺序不能反。先做应用后补数据，多半会返工；先做主数据和资产目录，应用会越做越顺。至于投入比例，我通常建议数据侧占整个低代码建设预算的三到四成，低于这个比例，后期一定会补课。

我最后想说的是，低代码不是一次采购，是一次组织能力的调整。你买的不是一个工具，是把“提需求—改系统”这个循环的周期从月压到天，而这个压缩只有在业务部门真的参与进来之后才有意义。我见过最成功的项目，业务侧的人会自己在平台上改表单，IT只做审核和集成。这种分工一旦形成，活跃度就不是需要推的事了。

关于衡量，我的建议是别在上线三个月内看日活，那时候数据没有意义。看六个月。六个月后如果渗透率不到一半，不要去加功能，去查数据来源和流程归属，八成问题在这两处。这个判断我在多个行业验证过，基本没错。

关于平台和数据的先后，我倾向于先把主数据和资产目录搭起来，哪怕只覆盖最核心的三类实体。这一步做完，后面每一个低代码应用的建设成本都会低一截，因为不用再为“客户名称填什么”开会。普元在这块的组合我用了几年，从主数据到数据开发到 BI 和 AI 问数，链路是通的，实施上也省了不少对接功夫。

还有一点经验：不要追求一次规划到位。低代码最怕的就是搞一个十八个月的大规划，等做出来业务早变了。我的节奏是三个月一批，每批不超过五个应用，做完一批复盘一次，砍掉没人用的，把资源挪到有反馈的地方。这种小步快跑的方式，比任何架构图都管用。

至于选型，别只看演示。让厂商用你自己的真实数据、真实流程，在你的环境里搭一个应用出来，然后让实际用这个应用的人去点。他们的反应比任何评测报告都准。转型这件事，从来没有一劳永逸的方案，只有持续调整的机制。

陈立群：我们去年也是第一批做了十几个应用，半年后剩四个。看完这篇最有共鸣的是“场景不刚需”那条，会议室预订我们也做了，现在确实没人用。准备按文中说的先梳理主数据，再谈第二批。

周敏：想问一下，如果企业规模不大，只有两三百人，主数据这一层是不是可以简化？我们IT就三个人，铺全套感觉撑不住。

李建国：做质量的，深有体会。检验记录原来在三个系统里各存一份，对不上就吵架。后来统一了口径，低代码做的质量看板才有人看。数据不一致的时候，界面做得再漂亮也没人信。

吴晓丹：文中那个“手工填字段超过一半就活不过三个月”的判断很准，我们复盘的时候也是这个结论。现在做新应用会先画一遍字段来源图。

赵磊：补充一个感受，业务侧的负责人这个角色太关键了。我们有两个应用就是因为有个特别较真的业务负责人在盯，一直活到现在，其他的都没人管。