很多企业第一次接触低代码，脑子里出现的画面，往往是拖一个表单，拉一条审批线，再做几个报表。
这当然是低代码的一部分。
但如果只看到这里，就很容易把低代码理解小了。
企业最头疼的，往往不是"能不能做一个表单"。
而是另一件事：
业务每天都在变，系统能不能跟着变。
比如，销售新加了一套项目报价规则，标准CRM里没有这个字段。采购要把供应商比价、交期、质检结果、付款条件放在一起看，ERP只能走采购订单。仓库多了批次、库位、冻结库存、在途库存，原来的库存表只能记一个总数。财务想看合同、发票、付款计划和回款风险，但这些数据分散在几个系统里。
这时候怎么办？
找软件厂商二次开发，周期长，费用高，还不一定排得上。让IT部门自己写，业务一变，又要重新改。继续用Excel和微信群，短期能跑，时间一长，数据、权限、责任全都说不清。
这才是低代码该上场的地方。
它不用来替代所有系统，也不该把所有人都变成程序员。
可以这样理解：标准软件管主流程，专业代码管底层硬活，低代码管夹在中间的那些变化。
这些变化，往往不大到值得重写一套系统，但又重要到不能一直靠Excel和群消息补。
所以，低代码开发到底有哪些应用场景？
图1：低代码适合承接变化快、跨部门、补系统缝隙的业务场景
我们不按软件名称来分。
因为只说OA、CRM、ERP、MES，很容易写成产品目录。
我们按企业每天真实发生的问题来分。
一、流程经常变化的场景
先看第一种：流程老变。
最典型的，就是审批。
但这里说的审批，不是简单的"提交、通过、驳回"。如果只是这么简单，用OA也能做。
麻烦的地方在于，企业里的审批往往带着大量业务规则。
比如报价审批。
普通报价可能销售主管批一下就行。但如果客户等级高、折扣超过一定比例、账期超过30天、产品涉及定制、项目金额超过50万，就可能要销售负责人、财务、交付负责人、总经理一起看。
再比如采购审批。
同样是买一批物料，如果是常规供应商、常规价格、常规交期，流程可以很短。但如果是新供应商、价格波动大、交期压得紧、涉及预付款，就要补供应商资质、比价记录、合同条款、质量要求和付款计划。
这些规则，今天可能这样，明天可能又变。
组织架构变了，审批人要变。金额权限变了，审批节点要变。业务新增了风险控制，表单字段要变。以前只看金额，现在还要看客户信用、库存占用、项目利润，判断条件也要变。
这种流程如果全部靠定制开发，会非常累。
因为每次改动都不大，但次数非常多。
低代码能帮企业做的，是把表单、流程、权限、规则、通知、日志放在一个可配置的环境里。
业务部门说得清规则，IT部门管得住边界，系统能在变化中持续调整。
所以，什么样的流程值得用低代码？看四件事。
第一，流程不是一次性工作，而是长期反复发生。
第二，流程里有字段、条件、角色、权限和记录要求。
第三，流程经常因为组织、规则、业务变化而调整。
第四，企业不希望这些判断一直留在微信群、Excel和个人经验里。
只要满足这几条，低代码就很值得考虑。
图2：流程频繁变化时，低代码可以把表单、规则、权限和日志配置化
二、Excel越补越多的场景
再看第二种：Excel越补越多。
很多企业不是没有系统。
恰恰相反，系统不少。
有ERP，有CRM，有财务系统，有仓库系统，有生产系统。可实际业务一跑起来，旁边还是会冒出一堆Excel。
销售有报价表。采购有供应商对账表。仓库有库存调整表。质量有异常问题台账。生产有缺料跟进表。项目经理有进度跟踪表。
为什么会这样？
不是员工喜欢Excel。
根子在系统里：字段不够用，流程不够贴合，跨部门数据串不起来。
比如质量异常。
车间发现一批产品不合格，现场先登记问题。质量部门要判断原因，生产要确认批次，仓库要冻结库存，采购要追供应商，销售要判断是否影响交期。最后还要有整改措施、责任部门、关闭时间和复盘记录。
如果系统里没有一条完整的异常处理流程，大家只能各记各的。
质量有质量表，生产有返工表，仓库有冻结表，采购有供应商沟通记录。每个表都是真的，但拼在一起才是完整事实。
这类表格，就适合用低代码收回来。
不是为了把Excel换个界面。
更重要的是，把原来藏在表格里的业务关系做出来。
谁发起，谁处理，谁确认。哪些字段必填，哪些状态不能跳。库存冻结后能不能出库，责任部门没填写能不能关闭，整改超期要不要提醒，历史记录能不能追溯。
Excel只能记数据。
低代码可以把数据背后的流程、权限和责任一起管起来。
差别就在这里。
图3：把散落在 Excel 中的数据、流程和责任关系收回系统
三、标准系统管不到的补充场景
第三种，是标准系统管不到，但企业又离不开的事。
很多企业上ERP、MES、WMS、CRM之后，会遇到一个很现实的问题：
主流程有了，但缝隙还在。
ERP能管订单、采购、库存、财务。MES能管生产执行。WMS能管仓库出入库。CRM能管客户和商机。
但企业的真实业务，往往不完全按照系统边界发生。
比如订单评审。
一张客户订单进来，销售关心价格和客户承诺，计划关心产能和交期，采购关心关键物料，仓库关心库存占用，财务关心账期和授信。
这件事很重要，但它不一定刚好属于某一个标准模块。
你放在ERP里，可能太重。放在CRM里，生产和采购看不完整。放在MES里，又离客户和价格太远。最后很多企业就开会，拉群，做Excel评审表。
这类事，用低代码会更顺手。
它不抢ERP、MES、WMS的主流程位置，而是在它们之间补一层业务协同。
订单评审应用可以从CRM拿客户和商机，从ERP拿库存和价格，从MES拿产能，从采购记录里看关键物料到货风险。评审结果再回写到订单、排产或交付计划里。
好处不只是多了一个入口。
原来靠人找人、表找表、会找会的工作，现在有了一个固定入口和完整记录。
这一类需求里，低代码主要补三件事：
第一，标准系统之间的协同流程。
第二，标准系统不愿意频繁改的轻量业务。
第三，企业自己独有的管理规则。
标准软件解决共性，低代码承接个性。
这个分工想清楚，很多系统建设问题就顺了。
图4：低代码适合补 ERP、MES、WMS、CRM 等系统之间的协同缝隙
四、数据采集和现场填报场景
第四种，发生在现场。
企业里有很多数据，不是一开始就天然待在系统里的。
比如设备点检、门店巡检、施工进度、售后回访、质量抽检、安全检查、客户拜访、现场整改。
这些数据有一个共同特点：发生在现场，格式不算特别复杂，但非常分散。
如果不及时记录，事后很难补。
设备有没有点检，谁点检的，拍了什么照片，发现了什么异常，异常有没有派单，维修有没有完成，备件有没有更换。这些事情如果靠纸质表格，月底再录系统，数据基本就晚了。
这类现场动作，可以用低代码做成移动端应用。
员工在现场打开表单，扫码设备，拍照上传，选择异常类型，填写处理说明。系统自动带出设备信息、责任人、点检周期和历史故障。发现异常后自动生成维修任务，超时没处理就提醒负责人。
现场采集不一定需要很复杂的技术。
但它需要足够贴近业务现场。
字段要能改，流程要能调，权限要能分，手机端要能用，数据要能汇总。
如果每个现场应用都从零开发，成本太高。如果继续用纸和表，管理颗粒度又太粗。
这类需求夹在"纸质表格太粗"和"定制开发太重"之间，低代码刚好有位置。
图5：现场采集类应用需要移动端、拍照、派单、提醒和追溯能力
五、看板和经营分析场景
第五种，是业务看板和经营分析。
这里要特别注意。
低代码做看板，不是把几个图表摆在大屏上就结束了。
如果只是展示销售额、订单数、库存金额、交付率，那很多BI工具都能做。
真正有用的看板，要能把结果和过程连起来。
比如老板看到本月交付率下降。
只看到一个数字，没有意义。
还要继续往下看：是哪个产品线下降，哪个客户延误，哪些订单卡住，卡在缺料、产能、质检、发货还是客户变更。再往下，还能看到责任部门、处理状态、预计恢复时间和历史类似问题。
做到这一步，看板才不只是展示工具，而是管理入口。
这类"能往下追"的经营看板，用低代码做会更灵活。
一边连接业务数据，一边连接处理流程。
看到异常，不再只是截图发群里问一句"怎么回事"。它可以直接发起任务、指定负责人、跟进处理、记录结果。
比如应收账款看板。
财务看到某个客户超期未回款，可以点进去看合同、发票、发货记录、对账状态、销售负责人和历史沟通记录。如果需要催收，可以直接发起回款跟进流程。
比如库存看板。
仓库看到某类物料库存异常，不只是显示红色预警，还要能看到在途采购、占用订单、冻结原因、替代料方案和采购负责人。
这类看板最重要的，是把"看见问题"和"处理问题"接起来。
否则，很多看板最后只会变成会议背景。
六、项目制和非标业务场景
第六种，是项目制、非标业务。
有些企业不是每天重复生产同一种产品，而是一个项目一个样。
比如装备制造、工程施工、软件交付、系统集成、定制化服务、咨询实施。
难点在于：流程有主线，但每个项目都会变形。
一个项目从立项、预算、合同、采购、设计、生产、安装、验收、回款，到售后服务，中间会牵涉很多部门。每个阶段都有资料、节点、责任人、风险和变更。
标准项目管理软件能管一部分，但企业自己的业务细节往往很多。
比如项目变更。
客户临时改需求，设计要评估图纸，采购要看物料是否重采，生产要判断是否返工，财务要确认是否加价，销售要重新签补充协议。
这件事也不是简单改一个任务截止日期。
它会影响成本、交期、库存、责任和回款。
低代码可以把项目过程里的关键节点做成应用。
项目立项、预算申请、变更评审、资料归档、风险台账、验收确认、回款跟踪，都可以围绕企业自己的管理规则搭起来。
它不一定替代专业项目管理系统。
但它可以把项目中那些最容易掉链子的环节管住。
项目越多，周期越长，变更越频繁，跨部门越多，低代码越容易发挥作用。
七、快速试错的新业务场景
第七种，是新业务、新流程、新管理方法还没完全稳定。
企业做新业务时，最怕一上来就买一套重系统。
因为规则还没跑顺。
今天这样定价，明天可能换一种渠道。这个月按区域管理，下个月可能按客户行业管理。刚开始只要记录线索，后来又要管合同、履约、回款和售后。
这个阶段如果直接上标准系统，容易出现两个问题。
要么系统太重，业务还没跑起来，员工先被流程拖住。
要么系统太死，业务刚有变化，又要花钱改。
低代码可以先做新业务的第一套系统。
先把核心流程跑起来：客户怎么进来，需求怎么记录，报价怎么审批，合同怎么归档，交付怎么跟进，数据怎么复盘。
等业务逐渐稳定，再决定是继续增强低代码应用，还是接入ERP、CRM、MES等专业系统。
也就是说，企业可以先用更低成本，把管理规则跑一遍。
这比用Excel试错更可控，也比一开始重金定制更灵活。
八、AI和低代码结合的场景
现在还要多看一层：AI正在改变低代码的使用方式。
过去做低代码，很多工作仍然需要人配置。
表单怎么建，字段怎么命名，流程怎么连，权限怎么设，页面怎么排，都需要实施人员理解业务后一点一点搭。
AI加入之后，低代码的入口会变得更自然。
业务人员可以先用自然语言描述需求：我要做一个供应商准入流程，包含资质上传、采购初审、质量审核、财务备案、到期提醒和黑名单控制。
AI可以帮助生成初步表单、流程草图、字段建议、页面结构和规则说明。
但企业系统不能只靠AI生成。
因为AI容易不稳定，也可能理解偏差。一次生成看起来不错，不代表长期运行没问题。字段口径、权限边界、审批责任、数据日志、接口回写，这些都必须落在稳定的平台能力上。
所以，AI和低代码放在一起，不是让AI随便生成一个系统。
更合理的方式是：AI提高搭建效率，低代码平台兜住运行秩序。
AI负责把需求快速翻译成初稿，低代码负责把数据、流程、权限、接口、版本和运维管起来。
这会让低代码从"拖拉拽工具"，慢慢变成企业系统开发的智能底座。
九、哪些场景不适合低代码
也得把边界说清楚。
并不是所有系统都适合低代码。
第一，特别底层、特别高并发、特别强调性能的系统，不适合主要靠低代码完成。
比如大型互联网交易系统、实时风控引擎、复杂算法平台、底层中间件。这类系统对架构、性能、稳定性要求极高，更适合专业代码开发。
第二，规则还没想清楚的业务，不适合急着做系统。
低代码能让系统做得更快，但不能替企业想清楚管理规则。如果连谁负责、怎么审批、数据口径是什么、异常怎么处理都没想明白，低代码只会把混乱更快地搬到线上。
第三，已经有成熟标准软件能很好解决的场景，不一定非要低代码重做。
比如标准财务核算、标准电商订单、标准人事薪酬，市场上有成熟产品，企业需求也没有明显差异，就没必要为了"可定制"而重新做一套。
低代码最怕被用错地方。
用在合适的地方，它是效率工具，也是管理工具。
用在不合适的地方，它会变成另一套需要维护的系统负担。
十、判断一个场景是否适合低代码，看这张表
企业判断一个业务要不要用低代码，不妨看下面这几个问题。
图6：判断业务是否适合低代码，要看变化频率、协同复杂度和系统覆盖度
|-------------|-------------------------|-------|
| 判断问题 | 如果答案是"是" | 适合程度 |
| 这个业务是否经常变化 | 流程、字段、角色、规则经常调整 | 高 |
| 是否跨部门协同 | 需要销售、采购、仓库、财务、生产等多方参与 | 高 |
| 是否长期依赖Excel | 表格越来越多，版本越来越乱，责任说不清 | 高 |
| 标准系统是否覆盖不到 | ERP、CRM、MES等主系统有边界，需要补缝 | 高 |
| 是否需要权限和日志 | 谁看、谁改、谁批、谁负责都要留痕 | 高 |
| 是否只是一次性任务 | 做完一次就不用了 | 低 |
| 是否对性能要求极高 | 高并发、低延迟、复杂算法 | 低 |
| 管理规则是否还没想清楚 | 责任、流程、口径都不明确 | 先别急着做 |
这张表，比单纯回答"低代码能做什么系统"更有用。
因为低代码不是按行业决定用不用，而是按业务特征决定值不值得用。
同样是采购，有的企业只需要标准采购订单，用ERP就够了。有的企业要管供应商准入、比价、样品试用、质量评分、合同变更、付款风险，这时候低代码就有空间。
同样是仓库，有的企业只要出入库，有WMS就够了。有的企业还要管借料、调拨、冻结、盘点差异、异常责任和跨部门确认，这时候低代码也能发挥作用。
最后总结一下。
低代码开发的典型应用场景，当然包括审批、表单、报表。
拆开看，主要是四类问题：
变化快的流程。
散在Excel里的业务。
标准系统之间的缝隙。
需要快速验证的新场景。
如果一个业务已经稳定、标准化、市场上有成熟软件，那就优先买标准系统。
如果一个业务非常底层、性能要求极高，那就交给专业代码开发。
但如果一个业务天天在变，跨部门很多，标准系统改不动，员工又不得不用Excel和群消息补流程，那么低代码就不是可有可无的工具。
它是企业把业务变化重新装回系统的一种办法。
这也是低代码真正值得被认真看待的地方。