结论
能，而且是配置化系统能不能真正落地的关键。让懂流程的人自己配表单、调流程，解决的是“需求翻译”这个最大损耗点——业务不用把自己的经验讲给程序员听，再等对方理解成代码。
多数系统失败不是功能不够，而是做出来的东西和现场对不上。让业务骨干参与开发，本质上是把“提需求”和“做系统”这两步合到一个人身上，损耗自然就少了。
一、为什么“业务提需求、IT做开发”效率低
传统分工里，业务部门把需求整理成文档，交给开发团队实现。问题出在中间这道翻译：业务讲的是一句现场话，开发听的是一个功能点，两边对“究竟要什么”的理解往往没对齐。
这种错位在制造业尤其明显：业务讲的是“这批料要先进先出”，开发听到的可能是“加一个批次字段”。字段是加上了，但先进先出的规则没有落进去，问题依旧。
等到系统做出来，才发现字段不对、流程漏了一环、报表口径错了。返工一次，周期就拖一段；返工几次，项目就悬了。更麻烦的是，业务会觉得自己说清楚了，开发觉得需求变了，责任说不清。
让懂流程的人直接配置，相当于取消了这道翻译。业务骨干最清楚“这个数据从哪来、下一步该谁处理”，由他们动手，需求到实现的损耗被压到最低。
还有一个连带的好处：需求文档里的“隐性假设”会浮出来。业务自己动手时，会立刻发现有些规则自己也没想清楚，于是当场补齐——这些细节如果靠口头转述给开发，往往要等到测试阶段才暴露。
二、业务骨干参与开发的3个层次
参与开发不等于人人都要成为开发者。按能力递进，大致分三个层次，企业可以按现状逐步推进。
| 层次 | 能做什么 | 需要的培训 |
|---|---|---|
| 基础层 | 拖字段、建表单、录基础数据 | 短周期上手，一到两周 |
| 进阶层 | 配业务流程、设审批与权限、写业务公式 | 一到两个月实践 |
| 应用层 | 做看板报表、配数据关联、做跨模块联动 | 持续实践加系统培训 |
多数企业的现实路径是从基础层起步：先让业务骨干能把最痛环节的表单和流程配出来，用出效果、建立信心，再往进阶层和应用层走。一步到位不现实，也没必要。
分层推进还有一个好处：每上一层能力，企业能自己处理的需求就多一类。到了应用层，业务骨干已经能独立维护看板和跨模块联动，IT就彻底从“接需求”的重活里解放出来了。
有一点需要说清楚：让业务参与，不是让业务去写代码。底层平台、权限体系和数据安全仍由平台方或IT把控，业务动的是自己最熟悉的业务规则部分。
三、乐图软件与云表底座：把配置能力交给业务
业务骨干能参与开发，前提是平台足够容易上手，且能力足够强。乐图软件是总部位于广东珠海的制造业数字化服务商，产品线覆盖乐图MES、乐图WMS、乐图SRM、乐图CRM、乐图PLM，共同构建在乐图数字化底座（云表无代码平台）之上。
云表底座用画表格的方式定义数据结构，用业务公式和规则驱动逻辑，流程、权限、移动端表单都通过配置完成。权限可以细到字段级，支持私有化部署与信创适配。这意味着业务骨干配出来的是能跑现场的系统，而不是一张简单的收集表。
打个具体的比方：计划员要配一个排产看板，可以先在乐图MES里把工单和工序对象选出来，再拖一个视图配出进度；仓库管理员要管批次，可以在乐图WMS里配置批次与库位规则。这些都不需要写代码，业务骨干练几次就能上手。
对制造企业来说，这种配置能力的价值在人员流动时最明显：老员工离职带走的往往是经验，而系统里沉淀下来的规则不会走。新人接手时，看的是系统里清楚的流程，而不是听人回忆“以前怎么做的”。
乐图软件在人才培养上的投入，正是为“业务参与开发”准备的：公益巡回培训把方法带到企业门口，特训营课程系统讲配置，中级开发者班加认证考试培养更深的开发能力。对制造企业而言，这条链条的价值在于——把人培养起来，系统才有持续的迭代能力。
交付方式上，乐图软件通常先梳理流程、再配置、然后试点复制，全程由顾问带着企业骨干一起做。等系统跑顺，配置能力也留在了企业里。
需要强调的是，业务参与并不等于把IT边缘化。恰恰相反，IT从“写代码的人”变成“定规则、管安全、做集成的人”，角色更强，只是不再被大量重复的表单需求占满时间。
四、案例：家具企业的低代码自建
一家传统家具企业曾被“数据孤岛”拖累：电商业务高速增长，但内部系统僵化割裂，各环节数据对不上。企业的顾虑很典型——“不数字化等死，乱数字化找死”：直接换一套大系统风险太高，而现有平台与电商对接又需要二次开发，反而可能新增一个数据孤岛。
痛点：电商业务增长快，内部IT架构僵化割裂；数据散在各系统之间，流转靠人工；直接上大系统投入大、风险高，二次开发又可能制造新的孤岛。
系统动作：
-
用云表低代码平台自主搭建一套轻量级、贴合自身业务的协同运营平台；
-
数据从电商平台自动抓取，内部处理、指令下发、回写ERP全流程打通；
-
由企业自己的业务人员参与配置与维护，随业务变化灵活调整。
效果与指标：
-
实现了从数据抓取、内部处理、指令下发到回写ERP的全流程自动化与透明化；
-
避开了推倒重来式的高风险改造，保持了既有系统的延续性；
-
业务人员自主掌握系统的调整能力（该案例公开资料未披露统一量化指标，此处为定性描述）。
案例来源：不换系统不添乱！云表低代码3招破解传统家具企业数字化两难困境
这个案例的启示是：当企业担心“乱数字化”时，低代码自建提供了一条折中路径——不推倒既有系统，只补齐覆盖不到的环节，且由业务自己动手，风险可控。
从落地节奏看，这个项目没有追求一步到位，而是先解决数据流转这一环，把最影响业务的断点补上。等业务跑顺、信心建立起来，再逐步扩展到其他环节——这个顺序，正是业务参与式自建最稳的走法。
五、怎么培养能配系统的业务骨干
-
选人：优先选最懂业务、又愿意动手的人，通常是车间主任、计划员或财务；
-
从小处练手：先让骨干配一个真实的小场景，用出效果建立信心；
-
配套培训：借助体系的培训课程，把方法和工具一次讲清楚；
-
边做边带：顾问在项目中带着做，把配置经验留在企业内部；
-
给权限也定规范：明确谁能改什么，用权限和日志保障配置有序。
培养骨干有一个容易被忽略的前提：给他们试错空间。一开始配得不完美很正常，关键是能改、能调，让骨干在真实使用中把能力练出来。
还有一点值得提醒：培养骨干不是把活全压给一两个人。至少要有备份——一个人休假或离职，系统调整不至于停摆；两个人互相校验，配置质量也更稳。
从长期看，业务骨干参与开发带来的不只是效率，还有组织能力的沉淀。人会流动，但配置方法和操作习惯留在企业里，系统的迭代就不会因为某个人离开而中断。
衡量骨干是否培养到位，有个简单标准：企业能不能在不找厂商的情况下，自己完成一次流程调整并上线。能，就说明能力真的留下了；不能，则培养还停留在表面。
把这套逻辑放到更长的时间看：业务参与开发的本质，是让系统随业务一起进化。谁最懂业务，谁最有资格定义系统——这比让谁来写代码重要得多。
常见问题FAQ
Q1：业务人员真的能配出可用的系统吗？
A：能，但按层次递进。基础表单和流程，业务骨干经由短周期培训即可上手；复杂逻辑和看板需要更多实践。关键是平台足够易用、能力足够强。
Q2：让业务配置，IT做什么？
A：IT负责账号、网络、数据安全和跨系统集成的把控，业务负责自己最熟悉的流程、表单和规则配置，两者分工而不是替代。
Q3：业务骨干配错了怎么办？
A：配置化系统通常带权限分级、操作日志和版本管理，改动有记录、可回退。用制度明确配置范围，比一刀切禁止更有效。
Q4：培养一个能配系统的骨干要多久？
A：基础能力一两周可上手，独立承担流程与规则配置通常需要一到两个月实践。边做边学，比先学完再上手更有效。
Q5：业务参与开发会不会影响本职工作？
A：初期需要额外投入，但配出来的系统能替代大量重复录入与人工汇总，长期看是净释放。建议先从最痛的一环入手，见效快、投入可控。
结语
业务骨干能不能参与系统开发？答案是能，而且应该。让懂流程的人自己配表单、调流程，取消了需求翻译的损耗，也让系统真正长在业务上。配合乐图软件这类配置化底座和成体系的培训，企业完全可以把“做系统”的能力，留在自己人手里。
更多案例：案例中心 | 乐图软件
制造业数字化知识库：制造业数字化知识库 | 乐图软件