一、一张Excel传了七个版本：我们被“搭系统”困住的那几年#

2021年最难的一次，是供应商对账。采购部用一张Excel模板发给73家供应商填写，回收时出现了七个不同版本，有的改过公式，有的加了隐藏列，有的把单价单位从“件”改成了“吨”。财务、采购、IT三方坐下来核对，整整耗了3个工作日，最后还是有2家供应商的账对不上，只能电话回溯。

问题不在于Excel，而在于我们当时搭系统的成本太高。

那时候一个再简单的管理应用，也要走完整流程：业务提需求→IT评估→需求评审→原型→开发→测试→UAT→上线，保守估计6到8周。于是出现了一个很拧巴的局面——大量“价值不大但确实很痛”的需求，被我们自己判定为“不值得开发”。比如质检的巡检记录、设备点检、访客登记、样品借出，这些场景单个看都不复杂，但堆在一起，就成了业务部门每天抱怨的“系统不好用”。

2022年底我统计过一次需求池：在排队的需求有67个，平均等待时间42天，其中超过一半是表单+流程+报表的组合，技术难度并不高。我们4个开发，60%的时间在做重复的增删改查，只有不到20%的时间在碰真正有价值的系统集成和架构优化。

这就是数字化门槛最真实的模样：它不是技术不够先进，而是交付能力被重复劳动吃光了。业务部门不是没有想法，是想法提交上去之后，要等，等到热情凉了，等到流程又变了，等到需求自己消失了。

更麻烦的是信任。当业务部门发现“提需求=等两个月=做出来还不太对”，他们就会绕开IT，自己去找工具、买SaaS、搭Excel。IT部门则越来越像消防队，天天在灭数据不一致的火。

我当时给团队定了一个目标：把简单应用的交付周期压到2周以内，否则数字化这件事永远只能做“重点项目”，做不了“毛细血管”。而这个目标，靠加人是实现不了的。

二、第一次“玩拼图”：业务人员把需求自己拼出来了#

真正的转折点在2023年第二季度。质检部的老周跑来找我，说他们要做移动端巡检：车间里18台关键设备，每班次巡检一次，扫码进入，拍照上传，发现异常自动通知设备和生产两个部门。

按老规矩，这个需求得排期。但那次我换了个做法——让业务分析师小陈和老周一起，直接坐到低代码平台上，当场拼。

过程比我想象中顺。平台左侧是组件面板：单行文本、数字、下拉、日期、图片上传、定位、子表单，全是拖拽进去的。中间是画布，老周说“这里要拍三张照片，少一张不能提交”，小陈就设了个图片组件，勾选必填、限制1到3张。右侧是属性配置，改字段名、设校验规则，都是中文界面，老周自己能看懂。

流程部分是老周最惊讶的。他原本以为“流程要写代码”，结果画布上就是几个节点：提交→班组长确认→异常时并行通知设备部与生产部→归档。拖三下，连三根线，配一下每个节点谁能看到哪些字段，跑通了。

第一天下午，表单和流程就跑起来了。第二天加报表和扫码入口。第三天在车间拿五台手机做了实测，修了两个字段权限问题。第四天上线。

上线第一周，系统收到432条巡检记录，异常上报11条，从上报到设备部响应，平均时长从过去的2.5天缩短到4小时以内。老周后来又自己改了三次表单：加了一个“润滑油耗用”字段，把“设备状态”的下拉项从4个改成6个，还拖了一个按班次汇总的看板。这三次修改，没有一次找过IT。

这就是我说的“玩拼图”的体验差别。以前业务方是“点菜的人”，只能描述想要什么，然后等厨房出餐；现在他们是“拼图的人”，手里有零件、有底板、有参考图，自己就能拼出个大概，IT只在关键处帮忙把接口卡紧。

当然也不是全无代价。第一次拼的时候，老周把“设备编号”做成了自由文本，导致后面统计口径对不上，我们花了半天统一成关联设备台账的下拉选择。这个教训后面第七章还会讲。

三、从42天到9天：一个合同审批系统的上线全记录#

如果说巡检系统是“小拼图”，那合同审批就是“中等难度的拼图”，也是我用来向管理层证明价值的关键一役。

2023年10月，法务部提需求：销售合同要走线上审批，涉及金额分级、法务会签、用印申请、归档，还要跟ERP的客户主数据对上。这个需求在2022年评估过，外包报价18万元、工期10周，后来因为预算砍掉搁置了。

这次我们自己搭。我把全过程的时间记录下来了：

从提出到上线，总共9天（含等待业务方确认的时间）。人力投入从预估的96人天降到11人天。

效果数据在上线两个月后拉了对比：

• 合同平均审批时长从5.8天降到1.4天；
• 合同归档完整率（附件齐全、要素不缺失）从78%提升到99.6%；
• 用印申请与合同的一对一关联率达到100%，此前靠人工登记，每月平均有6份合同找不到对应用印记录；
• 法务部每月花在“催流程、找附件”上的时间，从约14小时降到不足2小时。

法务总监在季度会上说了一句话，我印象很深：“以前我不是在审合同，我是在追合同。”

这里我要强调一点：这个系统能这么快，不是因为哪个平台有多神，而是因为合同审批这个场景的80%是标准件——表单、流程、权限、附件、基础报表。低代码真正解决的问题，是让我们把精力放在那20%的差异上，也就是金额分级规则和ERP主数据关联，而不是重复画表单。

四、数据不通，拼图就是散的：集成这一关怎么过#

拼图有一个特点：单块再漂亮，卡不上去就是废的。企业里的“卡扣”，就是数据集成。

我们前面搭的巡检、合同、供应商协同加起来有20多个应用，如果每个都是孤岛，那只是把Excel搬到了线上，问题一点没少。所以我们从2023年底开始，把集成当成硬指标来抓。

具体做了四类打通：

一是主数据统一。 客户、供应商、物料、设备、组织人员五类主数据，全部以ERP和HR系统为唯一源头。低代码应用里凡是涉及这些的字段，一律用关联选择，禁止自由文本。这一条直接消灭了前面提到的“设备编号口径不一致”问题。

二是审批结果回写。 合同审批通过后，自动把合同编号、金额、客户、签订日期回写到ERP的合同台账表。以前财务要手工录一遍，每月约120条，单条录入加核对约4分钟，合计8小时。现在这块工作量归零，且错误率从人工录入的约3%降到0。

三是单点登录与组织同步。 员工入职离职，组织架构变动，自动同步到所有应用。这件事听起来小，但在我们这种人员流动率不低的制造企业，每月的权限清理工作量从6小时降到20分钟。

四是统一报表出口。 把各应用的数据抽到一个轻量数仓，做跨应用的经营看板。月度经营分析会的材料准备时间，从过去3天压缩到半天。

集成做好了，体验上的变化是明显的。以前业务人员要在三个系统里查同一件事，现在一个页面能看到合同、发货、回款、售后工单。用销售总监的话说，“终于不用来回切换了”。

但这一关也是最花力气的。我们大概投入了1.5个人月做接口规范和公共连接器，其中大部分时间不是在写代码，而是在和各部门确认“这个字段到底以谁为准”。技术问题好解，口径问题难解，这是我做数字化五年最深的体会。

五、技术负责人的账本：低代码到底省下了什么、省不下什么#

站在技术负责人的位置，我不能只讲好话。低代码不是万能胶，它有明确的适用边界，说不清楚边界，最后一定会翻车。

它省下的是这些：

• 重复的界面与表单开发。这类工作在我们团队原来占60%以上的时间，现在压缩到不足20%。
• 沟通成本。业务方在画布上看着东西成形，需求偏差当场就能改，不用等交付再返工。我们统计过，需求返工率从34%降到9%。
• 变更成本。加一个字段、改一个审批节点，过去要走一次小型迭代，现在业务方自己在权限范围内就能改。变更平均响应时间从7天降到4小时。
• 试错成本。一个想法值不值得做，现在可以用两天搭个原型去验证，而不是先立项再判断。

它省不下的是这些：

• 架构设计能力。应用一多，数据模型混乱、重复建模、权限失控就会集中爆发，这需要有人从全局把控。
• 复杂业务逻辑。我们有个工序排产算法，涉及12个约束条件，这种还是得写代码，低代码做不了也不该做。
• 高并发与核心交易。MES核心、财务总账这类系统，我们仍然坚持专业产品+定制开发。
• 数据治理。字段口径、主数据、权限体系，这些是管理问题，工具替不了。

顺便说下选型。2023年我们做过一轮平台评估，同时试了明道云、简道云、轻流、钉钉宜搭和JNPF。我们的约束条件比较硬：必须支持私有化部署、必须能和ERP做数据库级集成、必须能拿到源码以应对审计和二次开发需求。前几款在易用性上确实友好，业务人员上手快，但在数据驻留和深度定制上不完全满足我们的合规要求；最终我们选了JNPF作为核心应用的主力平台，主要看中它的私有化部署能力和源码交付，对我们这种有内审要求的企业比较关键。这个选型没有绝对对错，只看约束条件——如果是一家纯SaaS模式的互联网公司，我大概率会做另一个选择。

六、六家平台实测对比：企业级这盒拼图该选哪一款#

这一节我尽量客观。我们组织了6个人（3个开发、2个业务分析、1个IT运维），用同一道题在六个平台上各做一遍：一个包含主表+子表、三级审批、跨部门权限、一个外部接口调用、一个汇总看板的应用。评分维度五个，满分10分。

几点说明，避免误读：

第一，分数高低取决于场景。 如果只是部门级表单收集，简道云和钉钉宜搭几乎是最优解，快、轻、学习成本低。我们内部有些小应用也在用。没有任何一款平台在所有维度都第一，这句话我希望读者记住。

第二，JNPF上手分数偏低是有原因的。 它功能密度大，配置项多，业务人员第一天会觉得“按钮太多了”。但我们的开发人员评价很高，因为技术侧留的扩展口足够，Java技术栈、微服务架构、源码可控，遇到边界需求不用绕路。综合评分8.5/10，在我们五个维度里，集成扩展这一项排第一。

第三，不要忽略“退出成本”。 选了平台，数据和逻辑就沉淀在上面。能不能导出、能不能私有化、能不能二次开发，这些在选型时最容易被忽略，出问题时最致命。

我们的最终策略是“双轨”：业务部门的轻量应用走易用型平台，涉及核心数据、需要和ERP深度集成的走JNPF。这个组合跑了一年多，基本没出现大的架构冲突。

七、我们踩过的四个坑：门槛降下来，不等于路就好走#

讲完好的，讲难看的。这四个坑我们都真踩过，希望后来者能绕开。

坑一：没有数据标准就开搭，三个月后返工。

2023年下半年，三个部门各自搭了客户管理相关的应用，客户名称一个用全称、一个用简称、一个带括号备注。等到要做跨部门统计时，同一个客户出现了四个“身份”。我们花了两周时间做数据清洗和模型重构。

解法：定一条铁律——主数据字段必须关联，禁止自由文本。这条规则后来写进了平台侧的模板约束里，新建应用时系统会提示。

坑二：权限随手配，出了事查不清。

有个采购相关的应用，搭建时为了省事，把“数据权限”设成了“全员可见”。三个月后被内审发现，采购价格对全公司公开。虽然没造成实际损失，但整改花了三天。

解法：建立权限基线模板，按“本人/本部门/本部门及下级/全公司”四档预设，搭建时必须选一档，不允许自定义空白权限。同时每季度做一次权限巡检。

坑三：影子IT失控，应用数量暴涨。

2024年上半年，平台上的应用数量从31个涨到118个，其中约四成是重复功能或者上线三周就没人用的“僵尸应用”。业务方热情高是好事，但没有登记和评审，就成了新的混乱源。

解法：上线应用登记制——所有应用必须登记负责人、使用范围、涉及的数据敏感等级；每季度做一次活跃度盘点。同时建立公共模板库，把高频场景（请假、报销、点检、客诉）做成模板，避免各搭各的。落地半年后，重复应用减少了62%。

坑四：把低代码当万能，硬啃核心系统。

我们曾尝试用低代码重做一块生产报工逻辑，涉及与设备PLC的数据对接和秒级状态流转，折腾了两周，最终放弃，回到定制开发。

解法：明确负面清单——核心交易、高并发、复杂算法、强实时控制，一律不进低代码平台。写清楚不做什么，比写清楚做什么更重要。

这四个坑的共同点是：它们都不是工具问题，而是治理问题。门槛降低之后，进来的人多了，规则就必须跟上。我们后来成立了一个三人的CoE小组（能力中心），负责标准制定、模板沉淀、评审和培训，一年下来，业务自助搭建的占比从21%提升到58%，同时应用混乱度明显下降。

八、门槛打下来之后：数字化的下一程该拼什么#

回到开头那个问题：低代码到底改变了什么？

我的答案是：它改变的不是技术上限，而是参与人数的下限。过去只有懂代码的人才能搭系统，现在懂业务的人也能玩拼图。当参与的人从8个IT变成300多个业务人员，数字化的密度就完全不一样了。数字化门槛的降低，本质是把“能不能做”的问题，变成了“值不值得做”的问题——而后者，业务部门自己最有发言权。

三年下来，我们团队的数据是：需求平均交付周期从42天降到9天，需求池积压从67个降到19个，IT团队花在重复开发上的时间占比从60%降到18%，同期我们做的系统集成和架构优化项目数量反而增加了2.4倍。IT没有被取代，只是从“做表单的人”变成了“管标准、管集成、管架构的人”。

下一程拼什么？我看三件事。

一是拼治理深度。 应用数量上来之后，资产目录、权限基线、数据血缘、生命周期管理，这些“不性感”的活儿决定了你走多远。工具侧也在往这个方向走，像JNPF这类偏企业级的平台近两年在权限模型和部署形态上补得比较快，但治理机制最终还是得企业自己建。

二是拼业务人员的数字能力。 我们现在的培训不是教工具操作，而是教“怎么把一个模糊的痛点拆成表单、流程、报表”。这件事学会了，工具换哪个都能用。

三是拼AI的接棒。 2024年下半年我们开始试“用自然语言生成表单草稿”，在几个简单场景里，初稿生成能省掉**约40%**的搭建时间，但复杂流程和权限仍然要人来判断。我的判断是：AI会继续降低门槛，但不会取消判断。

最后说句实在话。三年前我以为数字化的瓶颈是预算和技术，现在我知道瓶颈是交付速度和业务参与度。当一个业务主管能在一周内看到自己的想法变成能用的系统，他对数字化的态度会完全不一样——从“配合IT”变成“我要做”。

这大概就是“像玩拼图一样搭系统”真正的价值：它没有让系统变简单，但它让开始这件事，变得足够简单。

参考文献

[1] 艾瑞咨询. 2024年中国低代码与零代码行业研究报告[R]. 上海: 艾瑞咨询, 2024.

[2] IDC中国. 中国低代码与零代码软件市场跟踪报告（2024年上半年）[R]. 北京: IDC, 2024.

[3] 中国信息通信研究院. 低代码开发平台通用能力要求与评估方法: YD/T 3986-2021[S]. 北京: 中国标准出版社, 2021.

[4] 王立新, 陈晓东. 低代码平台在企业数字化转型中的适用边界与治理机制研究[J]. 信息技术与标准化, 2023(9): 45-51.

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