企业数字化里,有一笔账经常被漏掉:系统上线以后,每一次“小改动”要花多少钱。
销售想增加客户风险等级,采购要调整供应商准入条件,财务换了费用归集口径,生产部门希望工单暂停时自动通知计划员。每个需求单独看都不大,落到系统里却要重新确认字段、流程、权限、报表和接口,有时还要排开发、测试和发布时间。
业务部门等不及,就先用Excel补一张表,再建一个群催进度。IT部门也委屈:需求说的是“加一个字段”,落到系统里,六七个地方都可能受影响。
很多企业的软件成本,就是这样一点点堆起来的。大项目有预算,也有人盯;数量众多的小需求,却长期消耗业务和IT的时间。
所以,讨论低代码开发平台的优势,只说“开发快、成本低、业务也能参与”,还不够。企业更应该关心一套系统的全部使用周期:第一次做出来需要多久,以后改一次要付出什么代价,系统多了以后能不能统一管理。
低代码的主要优势,可以归纳为一句话:它把企业应用里反复出现的技术工作做成平台能力,让需求交付、业务变更、跨系统连接和长期管理都更容易控制成本。
这句话怎么理解?我们分五笔账来看。
图1:低代码价值的五笔账
一、开发账:常见能力不用每个项目重做一遍
做一套供应商管理系统,页面并不是工作量的全部。
供应商要填写基本资料、上传证照;采购要审核准入;质量部门要记录来料合格率;财务要核验开票和付款信息;不同角色只能查看自己有权限的数据;关键操作还要留下时间、人员和修改记录。
传统定制开发可以完成这些要求,但项目组通常要分别处理数据表、前后端页面、流程状态、用户权限、消息提醒、文件存储、操作日志和移动端适配。下一次再做合同管理、设备维修或项目验收,相似的基础工作还会出现。
低代码平台把这类通用能力做成数据模型、表单组件、流程节点、权限规则、报表和接口配置。项目组从已有能力起步,把主要精力用在供应商如何分级、哪些材料必须提交、什么情况需要现场审核、淘汰条件如何计算。
写代码只是其中一部分。需求分析、联调、测试和后续维护的工作量也会跟着减少,因为项目不必自己照看一整套基础设施。
这也是低代码开发速度快的原因。它没有让软件开发凭空变简单,只是把企业应用中重复率很高的部分提前产品化了。
图2:低代码把重复技术工作产品化
二、变更账:系统上线后,修改规则的成本更可控
首版开发只发生一次,业务变化会发生很多次。
还是拿供应商管理来说。假设企业新增了一条规定:关键物料供应商完成资料审核后,还要经过现场评估;评估没有通过,采购订单不能释放。
这条规则会影响供应商类别、准入状态、评估任务、审批权限、采购校验、统计报表,可能还会影响ERP接口。业务人员嘴里的一句话,到了系统里是一串相关修改。
图3:一条业务新规牵动多个系统对象
如果这些逻辑散落在多个页面、脚本和独立程序中,项目组首先要找到它们,再逐项修改和回归测试。原开发人员离职、文档没有更新,改动还会变成一次排雷。
成熟的低代码平台会把数据对象、流程、权限、页面和接口放在同一套模型中管理。字段在哪里使用,流程在哪个条件分支读取它,哪些角色可以修改,报表是否引用,都更容易定位。修改仍然要评审和测试,但影响范围不再完全依赖某个人的记忆。
这里才是低代码最容易被低估的优势。
企业买一套应用,通常会用很多年。组织调整、管理制度变化、客户要求变化、接口升级都会持续发生。第一次上线快几周固然有价值,此后每次变更都能少排一次长队、少重做一套基础功能,几年积累下来的差距更大。
换句话说,低代码把软件从一次性交付的项目,变成了可以持续调整的业务工具。
三、协作账:业务和IT可以围绕同一个运行版本讨论
图4:业务与IT围绕同一个运行版本确认规则
传统项目中,有一种浪费很难写进预算。
业务人员写需求文档,产品经理画原型,技术人员再把它翻译成数据结构和程序逻辑。开发完成后,业务一试,才发现“退回”在双方理解里根本不是一回事。
业务想的是:资料退回给供应商补充,原来的审核意见继续保留。
开发理解的是:流程退回上一步,重新提交后覆盖原记录。
双方都按自己的理解做了正确的事,结果还是要返工。
低代码提供了一个更直接的沟通载体。业务人员可以对着可操作的表单确认字段,对着流程实例确认责任人,对着不同账号检查数据范围。很多原本藏在文档里的歧义,会在原型阶段提前露出来。
业务参与也不等于把系统全部交给业务部门自己搭。更合适的分工是:业务负责人确认对象、规则和例外,IT团队负责数据结构、权限、集成、安全和发布,实施人员把这些内容转成可运行的应用。
低代码缩短的是中间的翻译链。业务不必等到验收时才看见系统,IT也不必只靠一份文字需求猜现场到底怎么运转。
四、连接账:新需求不必逼着主系统反复改造
企业很少只有一套系统。
ERP管理订单、采购、库存和财务,MES负责车间执行,CRM保存客户和商机,OA承接日常审批。可真实业务经常跨越这些边界。
例如客户投诉处理,需要读取CRM中的客户信息、ERP中的订单和发货记录,还要调用质量部门的调查流程,最后把赔付结果交给财务。把整套流程硬塞进任何一个主系统,都会遇到模块边界、升级成本和使用体验的问题。
低代码平台可以在现有系统之间增加一层业务应用。客户、订单等权威数据继续留在原系统,投诉受理、责任分派、原因分析、整改复核和赔付审批放到新应用里,再通过API或数据库接口交换必要信息。
图5:低代码承接跨系统业务流程
这种渐进式做法有两个好处。
第一,企业不用为了一个跨部门流程大改ERP、MES或CRM。
第二,散落在Excel、邮件和群聊里的协作过程,可以留下统一的状态、责任人和处理记录。
当然,接口接通只是开始。数据以哪个系统为准,失败后是否重试,重复写入怎么拦截,接口账号能操作哪些字段,都需要提前设计。低代码降低的是集成实现成本,数据责任不会因此自动消失。
五、治理账:应用做得越多,越需要统一的边界
图6:织信应用设计与资产管理界面
低代码让更多人参与应用建设,这既是优势,也会带来新问题。
如果每个部门都能随意建表、复制客户数据、连接外部服务,企业很快会出现另一种影子IT:应用数量增加了,谁负责维护、哪些数据能共享、离职后谁接手,却没人说得清。
企业级低代码平台需要同时提供开发环境、测试环境、生产发布、版本记录、权限控制、操作日志、组件复用和应用资产管理。IT部门可以规定哪些数据允许使用,哪些接口需要审批,谁有权发布生产版本,出现问题后怎样恢复。
这时,低代码的作用已经超出“做应用更快”。它还给大量分散需求提供了统一的建设规则。
微软、OutSystems、Mendix等平台的官方资料,都把应用生命周期、环境、权限和治理放在低代码能力的重要位置。原因很朴素:企业只有一两个小应用时,靠人盯还能维持;应用增加到几十个、上百个以后,没有统一治理,开发速度越快,混乱也来得越快。
六、低代码能不能做ERP、MES这类复杂系统?
可以,但要看平台能力,也要看企业准备把什么交给低代码。
ERP、MES、WMS等系统的复杂之处,不在页面数量。物料、BOM、工艺、工单、库存、质量记录之间的关系,状态如何变化,谁能修改,哪个版本生效,接口失败如何补偿,这些内容才构成系统骨架。
图7:复杂系统需要业务对象、平台能力和工程运行三层支撑
一款平台如果只能搭单表、简单审批和统计图,确实不适合承担核心系统。具备复杂数据模型、BPMN流程、细粒度权限、脚本和API扩展、多环境发布、版本与日志能力的平台,则可以用于建设ERP、MES、PLM、SCM、SRM、WMS、CRM和项目管理等业务系统,也可以只改造其中变化快、非标准化程度高的模块。
像织信Informat这类企业级AI智能开发平台,采用数据模型优先的设计方式,把表单、流程、权限、报表、接口和扩展开发放在同一套平台中。标准软件无法覆盖企业特定流程时,可以用织信Informat补充主系统,也可以围绕企业自己的业务对象建设定制系统。
不过,产品说明里的“支持”不能替代项目验证。企业仍要拿自己的物料层级、流程分支、权限范围、数据量和接口异常做PoC。低代码能做复杂系统,和任何平台都适合做复杂系统,是两回事。
七、为什么有些企业用了低代码,优势并不明显?
通常有四种原因。
1、平台只解决了页面,复杂逻辑仍靠零散脚本
首版看起来很快,后面每次修改都要找脚本、查依赖、人工回归。开发账省下来,变更账又花了回去。
2、业务规则没有定清楚
客户主数据谁维护、订单撤回后保留什么、质检不合格由谁关闭,这些问题没有答案,任何工具都会反复返工。低代码只能加快实现,不能替管理者作决定。
3、业务自己搭,IT最后兜底
缺少命名、权限、接口、测试和发布规范,应用会越做越散。等到数据泄露或接口出错,IT再接手,修复成本往往更高。
4、场景本身不适合
高度追求个性化交互的互联网产品、复杂底层算法、特殊硬件驱动、超大规模实时计算,往往需要更多传统开发。低代码可以参与其中的管理后台、流程和数据服务,没有必要包办全部技术层。
所以,低代码并没有消灭软件成本。企业会增加平台许可、培训、治理和一定的平台依赖。它的经济性来自复用:应用越多、变化越频繁、通用能力重复越明显,平台投入越容易被摊薄。
八、判断低代码优势能否兑现,可以做六项测试
选型时,企业可以拿一条真实业务流程跑完下面六项测试。
图8:低代码平台六项PoC测试
| 测试动作 | 需要观察的结果 |
|---|---|
| 新增一个会影响审批和报表的字段 | 页面、流程、权限、报表和接口的引用关系能否找到 |
| 修改一条正在使用的审批规则 | 在途流程怎样处理,新旧规则能否区分 |
| 用不同岗位账号操作同一张单 | 记录、字段和按钮权限是否符合职责 |
| 故意让外部接口超时 | 是否保留请求、响应和失败原因,能否安全重试 |
| 从开发环境发布到测试和生产 | 配置差异、审批记录、版本和回退路径是否清楚 |
| 再搭第二个关联应用 | 客户、供应商、物料等模型和通用组件能否复用 |
这六项里,第一项看开发和变更成本,第二、三项看业务规则,第四项看集成可靠性,第五项看工程管理,第六项看平台能否形成长期资产。
测试结果比“几分钟搭出一个页面”更有参考价值。一场演示说明不了多少,企业最终购买的是一套可以连续使用很多年的应用交付方式。
结语
回到标题,低代码开发平台的主要优势是什么?
开发更快,只是最容易看到的一层。
它更重要的价值,是把数据模型、流程、权限、报表、接口、版本和日志这些重复出现的能力集中起来,让业务需求可以更快进入系统,让后续变化有清楚的修改位置,也让IT有办法管理不断增加的应用。
低代码最值得算的一笔账,是今后每一次业务变化进入系统,要花多少钱、等多久、冒多大风险。
这笔账算清楚了,企业才知道自己需要的是一个表单工具,还是一套能长期承载业务变化的开发平台。