一、被需求追着跑的一天：一个IT负责人的真实日程#

先还原一个典型的周三。

早上8点40分，我刚到工位，质量管理部的人已经在会议室等着了——他们要一个“来料检验异常追踪表”，说下个月客户审核要用。9点30分，销售运营的同事发来消息，经销商订货的Excel又崩了，三个区域的数据对不上。11点，生产计划部要求把排产看板加两个字段，理由是“上周开会定过了”。下午2点排评审会，五个需求里我们只能承诺两个，剩下三个业务方当场脸色就不好看了。

这不是某一天的意外，而是那两年的日常。

我后来做过一次复盘统计，结论有点扎心：

最后两行是我最不愿面对的数字。我们花了22天做出来的东西，有三成几乎没人用。原因也不复杂：需求提报时业务方说不清楚，等排到开发时业务场景已经变了，交付出来的东西自然对不上。

更麻烦的是需求的性质变了。以前一年几十个需求，大多是财务、ERP这类“大件”；后来变成每个月几十个，全是车间看板、临时报表、审批流程这种“小件”——单个价值不高，但缺了它业务就卡在那儿。用传统的立项、评审、排期、开发、测试那一套流程去跑“小件”，就像用集装箱卡车送外卖。

那段时间我最常想的一个问题是：能不能让这些“小件”不做成项目，而是像用办公软件一样，谁需要谁就造一个？ 这就是后来我们理解“随用随造”的起点。

二、从排期三个月到当天上线：报销应用的前后对比#

真正的转折点，是一个看起来特别不起眼的场景：差旅报销补充流程。

我们公司有标准报销系统，但售后工程师经常要垫付现场备件的小额采购费用，金额小、频次高、票据杂，标准流程走不通。财务部手工用Excel登记，每个月月底集中核对，每次至少折腾3天，还经常对不上账。

这个需求在需求池里躺了三个多月。为什么排不上？因为它“不够大”——不值得立一个三个月的项目，但它每个月消耗财务和售后团队合计约26个工时。

我们后来用低代码平台重做了这个流程，从我接到需求到业务方开始试用，总共花了2天：第一天上午梳理表单字段和审批节点，下午配置表单、流程和权限；第二天上午对接了企业微信消息推送和一个简单的票据附件上传，下午找了5个售后工程师试用，改了两处字段校验规则就上线了。

上线三个月后的数据对比：

这个案例本身价值不大，但它给了我们一个重要的认知校准：“随用随造”不是把所有系统都推倒重来，而是把那些长期卡在“不值得立项”和“业务又确实需要”之间的灰色需求，用极低的成本消化掉。

顺带说一句，后来我们把这些零散应用统一迁到了同一套平台上管理。我们团队最终选用的方案是JNPF，主要看中它支持私有化部署、Java和.NET双技术栈，并且能导出源码做二次开发——这一点对我们这种有历史系统要对接、又不希望被平台锁死的制造业IT团队来说，是硬指标。当然这是后话，选型逻辑我在第六章详细展开。

三、业务人员自己上手：把“提需求”变成“搭应用”#

如果说前三个月我们只是让IT团队变快了，那真正让效率曲线拐弯的，是把搭建能力交到业务人员手里。

这件事一开始我是抗拒的。我的判断是：业务人员不懂数据结构，搭出来的东西一定是一团乱麻。事实证明我想对了一半——他们确实不懂，但他们也不需要懂。

我们做了一个实验：选了设备管理部的设备台账场景，让部门里一位做了八年设备管理、完全不会写代码的工程师，在IT只提供数据源和权限规范的前提下，自己搭一个“设备巡检异常上报”应用。

过程比我预想的顺利：

• 第1天上午：他花了2小时把原来Excel里的巡检表字段（设备编号、点位、异常类型、照片、处理人）搬进表单设计器；
• 第1天下午：拖拽配置了三段流程——发现异常→班组长确认→维修派工→闭环归档，每段流程都设置了超时提醒；
• 第2天上午：用平台的报表组件做了一个“异常分布看板”，按车间和异常类型统计；
• 第2天下午：我帮他接了设备主数据接口，避免手工录入设备编号出错。

第三天，这个应用在三个车间同时启用。从提出到全员使用，共3天。

三个月后我统计了一组数据，这组数据后来成了我在各种内部汇报里最常引用的：

在我们引入低代码平台的第7个月，全公司新增上线的业务应用中，由业务部门主导搭建的占比达到43%；这批应用的平均上线周期为4.2天，IT部门只承担了数据对接和上线审核工作。同期，IT团队承接的需求平均交付周期从22天降至4.5天，需求池积压量下降68%。

这背后其实是一个朴素的道理：最懂流程的人，就是每天被流程折磨的人。 过去他要通过“写需求文档→讲给产品经理→讲给开发→开发理解偏差→返工”这条漫长的链路来表达诉求；现在他可以直接把诉求变成一个能跑的应用，当天就能验证对不对。

当然，不是所有东西都适合业务人员自己造。我们后来划了一条清晰的线：涉及核心财务数据、涉及跨系统写入、涉及对外接口的应用，必须由IT主导；部门内部流程、数据采集、看板报表这类，业务自建、IT审核。这条线划清楚之后，混乱少了很多。

四、随用随造的底层逻辑：可视化建模如何撑起快速交付#

很多同行问我：低代码凭什么能快？是不是只是把代码包装成了拖拽，复杂一点就废了？

我的理解是，低代码真正的加速点不在“省掉了敲代码”，而在“省掉了重复表达”。传统开发里，同一份业务逻辑要被表达三次：需求文档里写一遍、数据库设计里画一遍、代码里写一遍，三次之间必然有损耗。可视化建模把这些表达合并成了一次——你画的表单、配的流程、设的权限，本身就是可执行的。

从我们两年多的使用体验看，真正撑起“快速”的是四个能力：

第一是数据建模。 表单设计器背后自动生成数据表结构和关联关系，我们要做的只是定义字段、类型和校验规则。一个中等复杂度的业务对象，从设计到可用通常不超过1小时。

第二是流程引擎。 审批流、分支条件、并行会签、超时提醒这些，配置化完成。我们做过的复杂案例是一个“质量异常升级流程”，涉及4级升级、7个分支条件，配置耗时约3小时——同样的东西用传统方式开发，保守估计要5个工作日。

第三是权限体系。 这一点经常被低估。业务应用最麻烦的往往不是功能，而是“谁能看哪些数据、哪些字段”。行级、列级、角色级的权限能在配置界面里点出来，这一项至少省掉30%的开发沟通成本。

第四是集成能力。 孤岛应用没有价值。低代码平台必须有标准的API、Webhook和数据库连接能力，能跟ERP、MES、企业微信打通。我们内部有个要求：任何一个低代码应用上线前，必须回答“它和谁交换数据”这个问题，答不上来的不予上线。

顺便说一个容易被忽视的体验细节：修改成本。传统开发最怕上线后改需求，改一次要走一遍完整流程。低代码的体验是，业务方说“这个字段要加个校验”，我打开设计器改5分钟，保存后即时生效，不用发版、不用停机、不用通知用户重新登录。这种“随手改”的体验，才是“随用随造”能够持续运转的关键——因为业务需求本来就是不断变化的，一个改不动的系统，再快也会很快过时。

五、三类场景实测：巡检、订货、审批的搭建过程与数据#

讲逻辑容易空，我把我们内部记录最完整的三类场景摊开来讲，含搭建耗时和实际效果数据。

场景一：设备巡检异常闭环（业务自建，IT配合）

• 复杂度：中等，含照片上传、定位、多级流转
• 搭建耗时：3天（业务人员主导，IT支持半天）
• 使用规模：覆盖3个车间、86台关键设备、日均提报约40条
• 效果：异常平均响应时间从17小时降至2.3小时，超时未处理工单比例从21%降至3.8%
• 关键经验：照片字段一定要设成必填，否则一线会偷懒不拍；离线暂存能力对车间信号差的场景是刚需

场景二：经销商订货协同（IT主导，业务深度参与）

• 复杂度：较高，涉及多组织、价格策略、库存校验、外部账号
• 搭建耗时：11天（含与ERP的库存接口联调4天）
• 使用规模：接入217家经销商，月均订单约1,400笔
• 效果：订单录入错误率从6.2%降至0.4%，从下单到确认的平均时长由26小时压缩到1.8小时，销售内勤岗位从3人减至1人（转岗而非裁员）
• 关键经验：外部用户体系一定要单独设计，不要和内部账号混在一起；价格策略的规则引擎建议先在测试环境跑满一周

场景三：跨部门费用审批（业务自建+IT审核）

• 复杂度：低，标准审批流
• 搭建耗时：1.5天
• 使用规模：覆盖7个部门，月均流程实例约260条
• 效果：审批平均耗时从4.7天降至0.9天，流程在途查询的咨询工单量下降82%
• 关键经验：审批节点的“代理审批”和“转办”功能一定要提前配置好，否则节假日直接卡死

这三类场景有个共同点：它们都不是什么“大系统”，但每一个都曾经在需求池里躺着超过一个月。 据我们内部统计，这类“小而急”的需求占全部需求的比例约为64%，但消耗的排队等待时间占到了总等待时间的七成以上。低代码带来的最大改变，不是把大项目做得更快，而是让这64%的长尾需求不再需要排队。

值得一提的是，据某咨询机构2025年发布的《中国企业低代码应用成熟度调研》，在已引入低代码平台的样本企业中，需求平均响应速度提升41.6%，业务部门对IT的满意度评分从6.1分提升至8.4分（10分制）。这个数字和我们自己的体感基本吻合。

六、选型体验清单：技术决策者真正该看的六个维度#

这是我最想认真写的一章，因为我们踩过坑。第一次选型时，我们被demo的流畅度打动了，上线三个月后发现私有化部署受限、复杂流程跑不动、想改底层逻辑改不了，最后不得不二次选型，浪费了大半年。

后来我总结了一张自己的评估清单，六个维度，每个维度都有明确的验收动作，而不是听销售讲：

① 部署与数据主权。 制造企业几乎不可能把生产数据放到公有云。必须确认是否支持私有化/本地部署，以及部署后的升级方式。

② 技术栈兼容性。 团队是Java背景还是.NET背景？平台能不能融入现有技术体系，决定了后期的维护成本。

③ 复杂流程承载力。 别只看三级审批demo。让对方现场配一个“并行会签+动态审批人+超时自动升级”的流程，看能不能配出来。

④ 集成与扩展边界。 问三个问题：能不能调外部API？能不能被外部系统调用？能不能在平台内写自定义脚本或插件？

⑤ 代码可控性。 这一点对我们至关重要——能不能导出源码？如果不能，业务长大后要不要付出迁移代价？

⑥ 总拥有成本。 不只看授权费，还要算实施费、培训成本、后续扩容的阶梯价格。

按这六条，我们把当时接触的几款主流平台做了一次横向梳理（以下为我们团队的实际体验结论，仅供参考，不同企业需求差异较大）：

我们最终选择JNPF，核心理由是第②和第⑤条——它能融进我们既有的Java技术栈，并且支持源码导出，这意味着即便将来平台不再满足需求，我们的业务资产也不会被锁死。这个判断在第二年得到了验证：我们有一个应用因为性能要求提升，直接把导出的源码做了定制改造，平稳过渡。

七、别让“随用随造”变成“随造随乱”：治理与集成体验#

如果说前半年我们在享受“快”，那后半年我们主要在解决“乱”。

问题出得很典型：业务部门自己搭的应用越来越多，三个月内冒出60多个。然后开始出现各种状况——同一个“客户名称”字段，三个应用里三种写法；离职员工的账号还在流程里挂着；有个应用把公司通讯录全量同步到了一个公开表单里。

我们痛定思痛，定了五条规矩，执行之后混乱基本收敛：

第一，应用准入清单。 明确哪类应用业务可自建、哪类必须IT主导。核心数据（财务、客户主数据、人事薪酬）相关的一律IT主导。

第二，主数据统一。 所有应用必须引用统一的数据字典，不允许自建“客户表”“物料表”。这一条消灭了大约70%的数据不一致问题。

第三，上线审核制。 业务自建应用上线前，IT做一次轻量审核，检查权限配置、数据来源、是否有对外暴露。审核平均耗时30分钟，但拦下了不少隐患。

第四，生命周期管理。 每个应用登记负责人和用途，每半年盘点一次。我们第一次盘点就下线了19个长期无人使用的“僵尸应用”，释放了平台资源，也降低了维护负担。

第五，集成优先级。 优先打通企业微信/钉钉的消息通道和统一身份认证。这一件事做完，所有低代码应用的体验立刻上了一个台阶——用户不用记新密码，审批消息直接推到手机上。

治理这件事，我的体会是：“随用随造”考验的不是搭建能力，而是秩序感。 一个没有治理的低代码环境，半年就会变成新的技术债泥潭。反过来说，治理做好之后，业务部门的自建热情并没有下降，因为大家发现规则清晰反而更省事——他们不用再纠结“这个字段该叫什么”，直接引用标准字典就行。

八、从工具到能力：团队角色和协作方式的悄悄改变#

两年下来，最大的变化其实不在工具层面，而在人。

IT团队的角色变了。 以前我们是“需求承接方”，每天被追着问排期；现在我们更像“平台运营方和能力输出方”——维护数据底座、制定规范、做复杂集成、给业务团队做培训。我们12个人的团队，支撑的业务应用数量从两年前的40多个增加到现在的180多个，人数没变。

业务部门多了一个新角色。 我们内部叫“应用管理员”，每个部门选1~2个对流程最熟、电脑操作最利索的同事，接受两天培训，负责本部门应用的日常维护。目前全公司有23位这样的应用管理员，其中19位完全没有编程背景。他们承担了大约六成的日常调整工作——改个字段、加个审批节点、调整一下报表维度，不用再找IT。

沟通方式也变了。 以前需求评审会经常吵，因为业务方讲不清楚、IT听不懂。现在很多需求讨论直接变成“我搭个原型你看”，半小时就能对齐。原型即需求，这件事对沟通效率的提升，比任何流程规范都管用。

心态的变化可能最重要。 以前业务部门提需求，心态是“提了也不知道什么时候能做”；现在他们知道，只要不是特别复杂的，几天内就能有东西用。这种预期变化，让“被需求追着跑”的紧张感缓解了非常多。据我们内部季度满意度调查，业务部门对IT服务的评分从两年前的6.3分提升到8.6分（10分制）。

说句实话，低代码并没有让IT团队变轻松，但它让我们从“疲于应付”变成了“有余力做规划”。这个转变，对一个信息中心来说，价值是巨大的。

九、写在最后：让需求不再追着你跑#

回到标题那个问题——怎么才能不被需求追着跑？

我们这两年的答案有两条。第一条是分流：把那些“小而急”的长尾需求从主开发流水线上分出来，用低代码的方式就地消化，不让它们占用大项目的排期资源。第二条是赋能：把搭建能力交给最懂流程的人，让需求在被提出的地方就被解决，而不是经历一条漫长的传递链路。

“随用随造”听起来很理想主义，但落到实处其实很朴素：让一个业务应用从想法到可用，从三个月缩短到三天。 当这个时间差被压缩到足够小，需求的洪流就不再是压力，而是可以被一勺一勺舀走的日常。

如果你们团队现在正处在需求池越堆越高、业务方脸色越来越难看的状态，我建议先做两件小事：一是把过去半年的需求拉出来，看看“小而急”的占比到底有多少；二是挑一个最不起眼、最让你头疼但又不值得立项的场景，用低代码试一次。等那个应用两天后跑起来、业务方说出“这么快就好了”的时候，你就知道这条路走不走得通了。

别一上来就想着平台化、想着全员推广，先从一个小场景开始。快速见效的体验，比任何一份选型报告都有说服力。

参考文献

[1] 中国信息通信研究院. 中国企业低代码/无代码应用发展研究报告[R]. 北京: 中国信息通信研究院, 2024.

[2] 艾瑞咨询. 2025年中国低代码行业研究报告[R]. 上海: 艾瑞咨询研究院, 2025.

[3] 王建伟, 李思远. 可视化建模在企业业务应用快速交付中的实践[J]. 信息技术与标准化, 2024, 42(8): 56-63.

[4] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner Research, 2024.

[5] 张颖, 陈立. 制造企业数字化转型中的低代码治理机制研究[J]. 制造业自动化, 2025, 47(3): 112-119.