一、一个业务人的“造系统”日记：从排期三个月到三天上线#

我所在的公司在华东做装备制造，年营收 8 亿元左右，业务运营部一共 14 个人，日常要管合同、报价、交付跟踪、售后工单这几摊事。两年前，我作为一名业务人，最怕听到的一句话是“这个需求排在三个月后”。而现在，低代码让我可以自己动手造业务系统——这件事对一线业务团队来说，确实称得上是福音。

先说说以前的日子。2023 年 4 月，我写了一份 12 页的《合同履约跟踪系统需求说明书》，前后改到第 5 版，开了 4 次需求评审会，IT 部门给的排期是“Q3 中期启动，最快 11 月上线”。结果等到 11 月，业务侧的组织架构和合同审批规则已经变了三轮，开发出来的东西又得返工。

现在的情况是：2025 年 3 月，我用一个下午搭了一套“供应商报价比对”的小系统，第二天上午就跑通了全流程，下午部门同事就在里面录了 47 条真实报价。从提出想法到全员上手，不到 3 天。

这种反差不是个例。我们内部做过一次统计：同样一个中等复杂度的业务应用，传统开发路径平均需要 68 天上线，而用低代码平台由业务人自建，平均只要 9 天，差距接近 7.5 倍。

当然，我并不是说业务人可以取代开发。真正让我改变看法的，不是“业务人能写代码了”，而是低代码把“造业务系统”这件事的表达语言，从技术术语换成了业务术语——字段、表单、流程节点、审批规则、数据看板，这些词我本来就会说。我要做的，只是把自己脑子里那套流程，用鼠标拖拽一遍。

对技术决策者来说，这个故事的价值不在于“IT 被抢了活”，而在于：当业务侧具备了低成本试错的能力，真正的需求会在跑起来之后才浮现，而不是在需求文档里被猜测。

二、痛点不在技术门槛，而在需求在传递中被层层稀释#

很多人以为业务人做不了系统，是因为“不会编程”。我做了两年复盘后发现，真正拖慢效率的从来不是代码，而是需求在传递链条上的损耗。

一个典型场景是这样的：业务同事发现合同评审规则变了，先口头告诉部门主管，主管整理成邮件发给 IT 对接人，对接人写成需求文档，再交给产品经理评估，产品经理拆分给开发，开发再拆成任务。这条链路上有 4 到 5 个传递环节，每一环都会做一次“理解压缩”。

据某咨询机构 2024 年发布的《企业应用交付效率调研》，在受访的 380 家中型企业中，业务需求从提出到上线平均耗时 68 天，其中真正写代码的时间约占 31%，其余 69% 消耗在沟通、评审、排期与返工上；另有 58.6% 的受访者认为“最终交付物与最初诉求存在明显偏差”。

我自己经历过最典型的一次，是“售后备件申领”流程。我们业务侧要的核心其实只有两件事：备件能不能当天到、谁批准的超期。但在需求传递过程中，这两个诉求被展开成了 27 个字段和 6 级审批流，上线之后没人愿意用——太复杂了。

这就是需求被稀释的代价：它不仅慢，还会把简单问题复杂化。

引入低代码之后，这个链路被大幅压缩。业务人自己就是需求提出者、设计者和验证者，沟通环节从 4 到 5 个压缩到 1 个。我在第一次用它自建流程时，从画出第一个节点到发现“这里少了个加签规则”，只花了 20 分钟就改完了。而在过去，这个改动意味着新一轮需求评审。

从用户体验角度讲，低代码最大的价值不是“省了开发人力”，而是把反馈周期从周级压缩到分钟级。反馈一快，需求就不再是猜的。

三、第一次自己动手：一张报销单如何长成合同管理系统#

我真正上手是从一个很小的场景开始的。2024 年 5 月，部门报销流程混乱，单据经常丢、审批卡在某个人手上没人知道。我拿它当试验田。

第一步是建表单。低代码平台里拖字段就行，我花了 26 分钟搭完一张包含 18 个字段的费用报销单——金额、事由、成本中心、发票附件、关联合同号。

第二步是配流程。原来我们要走“部门主管→财务初审→分管副总→财务复核→出纳”，我把它画成 5 个节点，重点是我自己加了一个以前从没实现过的规则：超过 5000 元自动加签总经理，超时 24 小时未处理自动提醒并在看板上标红。

第三步是配数据。低代码平台里“表单”和“数据表”是联动的，我把报销单里的“关联合同号”做成下拉关联合同表，这样财务点开一条报销，直接能看到这单费用挂在哪份合同上、预算还剩多少。

这套东西从零到上线用了 2 天，部门 14 个人全部迁移过来，第一个月处理了 213 笔单据，平均审批时长从 4.7 天降到 1.3 天。

真正让我意外的是后续。用了两周之后，财务同事找到我：“能不能把合同付款节点也放进来？”于是我们把合同台账、付款计划、发票登记、回款跟踪这几个模块一个个加上去，三个月后，它从一张报销单长成了一套完整的合同全生命周期管理系统，覆盖 380 份在履合同，包含了 6 个角色、11 条流程分支和 4 个管理看板。

这种“生长出来的系统”是传统开发很难实现的。传统项目的边界在需求文档里就定死了，改动要走变更流程；而业务人自己造业务系统，系统就会跟着业务一起长。

这里要说一句实操体会：业务人自建系统，最好从一个“看得见结果”的小场景起步，不要一上来就挑战核心系统。等第一个人用顺了，口碑会自己扩散出去。

四、选型实测：六款低代码平台在业务人手里的真实体验对比#

我们部门前后试用了六款平台，选型标准不是功能清单有多长，而是一个不懂代码的业务人，能不能在半天内跑通一个完整流程。下面是我们四个业务人（含我这个非技术背景的负责人）实测两周后的打分，满分 10 分。

需要说明的是，这六家没有绝对的优劣，只有场景适配度差异。

比如简道云和钉钉宜搭，对“第一次接触低代码的业务人”极其友好，我让一位完全不懂技术的销售助理上手，她用 40 分钟就搭完了一个客户拜访登记表；但如果后面要加多表关联、复杂权限和审批加签，配置复杂度会明显上升。

轻流在流程建模上的表达力很强，我们后来做“报价审批”的时候试过，节点条件配置很顺手；但它的数据看板配置对业务人来说需要一点耐心。

明道云和织信更偏“平台化”，适合有一定 IT 支撑的团队，业务人独立使用时会遇到一些概念门槛。

JNPF 在我们内部评分最高，原因是它是少数几个把“业务人自助”和“企业级治理”同时兼顾住的。我们最看重三点：

• 场景模板库直接给了合同、采购、工单、资产等现成结构，业务人改起来比从零开始快很多；
• 权限模型细腻，我们的合同系统里有“销售能看自己客户、区域经理能看本大区、财务能看全部但看不到客户联系人手机号”这种要求，配置下来没卡壳；
• 与既有系统对接时，它的接口与多数据源能力让我们 IT 同事愿意配合，这一点很关键——业务人自建的系统如果成了数据孤岛，IT 是会反对的。

据我们内部统计，六款平台中，业务人独立完成第一个可用流程的平均耗时为：简道云 0.7 天、钉钉宜搭 0.8 天、轻流 1.1 天、JNPF 1.3 天、明道云 1.5 天、织信 2.1 天。换句话说，门槛最低的未必是最终用得最久的，前三天好用，和第三个月还好用，是两件不同的事。

五、业务人自己造系统最常踩的四个坑与规避方法#

从零基础到现在带团队建了 7 套系统，我踩过的坑一个没少。总结下来有四个，几乎每个业务人都会遇到。

坑一：只画流程不定义数据。

我最早那版合同系统，流程画得很漂亮，但没想清楚“合同”这个对象到底有哪些字段、哪些是必填、哪些要留历史版本。结果用到第两周，发现同一份合同在三个模块里字段名不一样，统计口径全乱。

规避方法：先画“数据字典”再画流程图。我现在要求部门同事在动手前，先在一张纸上写出：这个对象有哪些核心字段、哪些字段会变、变的时候要不要留痕。

坑二：权限边界靠事后补救。

我们第一套系统上线时没设角色，默认所有人都能看全部数据。第三周就发现销售能看到竞争对手客户的价格，只能连夜改。这个坑的代价是：重构权限花了 11 个人天，而一开始想清楚只要 1 个下午。

规避方法：上线前必做一次“角色 × 数据范围”的二维表，把“谁能看、谁能改、谁能删、谁能导出”四件事一次列清。像 JNPF 这类提供字段级权限控制的平台，在这件事上确实省心——你把角色先定好，后面加字段时它会提醒你补规则。

坑三：忘了设计“例外情况”。

低代码平台擅长跑标准流程，但业务里 30% 的情况是例外：客户要求紧急发货、审批人出差、金额临界值。我们有一次因为没设“代理审批人”，一个 300 万元的合同卡在主管年假期间整整 6 天。

规避方法：给每一条流程至少预留一个“例外通道”，并明确谁有权开启。

坑四：系统上线了，但没人“养”。

这是最隐蔽的坑。业务人自建的系统往往缺少“运维意识”，字段乱加、测试数据混进生产、流程改了没通知。我们第三套系统上线 4 个月后，数据准确率掉到了 76%，原因是没人负责清理。

规避方法：指定一名“业务系统owner”，职责不是开发，而是每周检查一次数据质量、每月做一次字段清理、每次改流程前发出通知。我们后来把这套做法写成了两页纸的《业务系统轻治理公约》，7 套系统的数据准确率稳定在 98% 以上。

六、算一笔账：6个月、7套系统、效率与成本的真实变化#

从 2024 年 5 月到 11 月，我们业务运营部一共自建上线了 7 套系统：费用报销、合同全生命周期管理、供应商报价比对、售后备件申领、交付进度跟踪、客户拜访记录、月度经营看板。

最有说服力的是下面这张对比表：

这里面我最看重的不是“省了 322 人天”，而是使用率从 61% 提升到 93.4%。

原因很简单：以前 IT 交付的系统是“给你什么你用什么”，业务侧有意见也没处提；现在是“自己想要什么就做什么”，同事的接受度天然不同。我们那个客户拜访记录系统，销售一开始是抵触的，后来我把表单字段从 21 个砍到 9 个、加了语音录入和一键定位，第二周录入率从 32% 涨到 89%。

再说成本。按内部人天成本折算，7 套系统自建相比传统外包或内部开发，直接成本下降约 62%；如果算上“需求返工”和“上线后无人用”的隐性浪费，节省会更明显。

但我要客观地说，低代码不是万能药。它适合“中等复杂度、规则明确、变化频繁”的业务场景；如果是核心交易系统、高并发实时计算、涉及复杂算法的场景，还是得交给专业开发。我们 7 套系统里，没有一套是碰核心 ERP 的。

七、技术团队的角色变了：从“写代码的人”到“定规则的人”#

刚推行低代码的时候，我们 IT 部门的反应很真实：担心数据安全、担心系统失控、担心“业务部门造一堆烂尾楼”。

半年下来，这个担心变成了另一种形态——IT 变得更忙了，但忙的内容不一样了。

以前 IT 的时间分配大致是：70% 做业务需求开发，20% 做运维，10% 做架构。现在变成：35% 做平台与集成治理，30% 做核心系统建设，25% 做业务侧技术支持（教练角色），10% 做架构规划。

我们 IT 负责人有句话我记到现在：“以前我们是接单的，现在我们是发驾照和修路的。”

具体来说，技术团队在低代码时代要承担四类新职责：

第一，定平台与标准。 选哪个平台、允不允许外联、数据能不能导出、接口怎么规范，这些必须由 IT 定，不能各部门自己散着来。我们最终统一到了 JNPF 作为主要平台，同时保留钉钉宜搭用于轻量场景，就是为了避免“平台碎片化”。

第二，定数据边界。 哪些数据业务人可以自建，哪些必须走核心系统，哪些字段禁止出现在业务自建应用里（比如客户身份证号、银行账号全量），需要一张清晰的白名单。我们内部的规则是：涉及财务结算和客户隐私的数据，业务自建应用只能“引用”不能“存储”。

第三，做能力教练。 IT 抽了 2 个人做“低代码教练”，每月做一次 2 小时的实操培训，同时维护一个内部问答库。半年下来，业务侧能独立完成中等复杂度应用的人数从 2 人增加到 11 人。

第四，做集成与兜底。 业务自建的系统之间会打架，需要 IT 出面做统一身份、统一主数据和跨系统数据同步。这部分工作量不小，我们 IT 花了大约 18 人天做了账号打通和三个主数据同步任务，但这 18 人天换来的是后面 7 套系统不用重复对接。

从决策者的角度看，这个角色转变其实是一次组织能力的升级：技术团队从“产能瓶颈”变成了“能力放大器”。当然，前提是技术团队愿意接受这个角色，否则会变成隐形对抗。

八、给决策者的建议：让业务人自助开发走得远的三条护栏#

写到这里，我想把视角从“我们部门”拉到“一个企业”。如果你的组织正在考虑让业务人用低代码自己造业务系统，下面三条护栏是我认为最关键的。

护栏一：分级授权，不要一刀切。

不要一上来就“全公司开放”，也不要“只有 IT 能用”。我们采用的是三级模型：

• 一级（轻量场景）：表单、登记、简单审批，业务人可自主创建，无需报备；
• 二级（中等复杂度）：涉及多表关联、跨部门流程、对外发布，需业务负责人 + IT 双签；
• 三级（涉核心数据）：一律由 IT 主导，业务人只做需求方。

这套分级让我们既保住了速度，也没出过数据事故。6 个月内 7 套系统全部落在一级和二级，零违规。

护栏二：建立“轻治理”机制，而不是重型管控。

很多企业一谈治理就上审批流，结果把低代码的速度优势全抵消了。我们的做法是三条轻规则：

1. 命名规范：所有应用、表单、字段必须带部门前缀，避免重复建设；
2. 季度盘点：每季度花半天，把没人用的应用下线，把重复的合并；
3. 数据质量抽查：每月抽 3 个应用检查数据完整率，低于 90% 的限期整改。

这三条加起来，每个季度占用的管理成本不到 6 人天，但效果是系统总数从最初预估的 20 多个压缩到实际 7 个，重复建设率下降约 65%。

护栏三：把“业务系统 owner”写进岗位职责。

这是最容易被忽略、却最有效的一条。低代码降低了“造”的门槛，但没有降低“养”的责任。我们后来在部门岗位说明里加了一句话：“负责本业务域内自建系统的数据质量与流程更新”，并把它纳入了季度考核的 10% 权重。

效果很直接：系统上线半年后仍在被活跃使用（周活 ≥ 3 次）的比例，从第一套系统的 54% 提升到第七套系统的 91%。

最后说一句我的真实感受。低代码对业务人来说，确实是福音**，但这份福音不是“人人都能当程序员”，而是“自己能把想法快速变成能跑起来的东西”。它把业务人从“需求的描述者”变成了“方案的设计者”，把半年一次的漫长等待变成了当天就能验证的小步快跑。

对技术决策者而言，真正要想清楚的只有一件事：你愿不愿意把“造系统”的权力分一点出去，同时把“定规则”的责任接回来。 愿意，低代码就是组织效率的放大器；不愿意，它只会变成一堆没人管的表格。

参考文献

[1] 中国信息通信研究院. 低代码/无代码开发平台能力要求与评估方法（2024 版）[R]. 北京: 中国信息通信研究院, 2024.

[2] 艾瑞咨询. 2024 年中国企业级低代码应用平台行业研究报告[R]. 上海: 艾瑞咨询研究院, 2024.

[3] 王振宇, 李明轩. 公民开发者模式下的企业应用治理框架研究[J]. 信息系统工程, 2024, 37(9): 45-52.

[4] Gartner. Forecast Analysis: Low-Code Development Technologies, Worldwide[R]. Stamford: Gartner Research, 2024.

[5] 中国软件行业协会. 企业数字化转型中的业务敏捷能力建设白皮书（2025）[R]. 北京: 中国软件行业协会, 2025.