如何通过低代码平台快速开发？

我想，很多人对低代码应该都有这么一种感觉。

用它做个表单、审批和简单管理系统，确实挺快。但真要拿它开发ERP、MES、供应链或者售后服务系统，可能就没那么靠谱了。

为什么？

因为我们平时看到的低代码，大多是拖几个字段、画一条流程、配几张报表。很快能做出页面，也很快能跑通审批，看上去确实比传统开发省事。

可企业真正要用的系统，哪有这么简单。

比如，一套售后工单系统，开始可能只有四步：客服登记问题，主管派单，工程师填写处理结果，客户签字。

运行一段时间后，新情况就来了。

一张工单可能需要两次上门；工程师到了现场，发现缺少配件，工单要先暂停；客户验收不通过，需要退回继续处理；已经派出的任务临时换人，原来的派工记录还得保留。

业务只是多了几个例外，系统却要同时调整数据、流程、权限、报表和历史记录。

所以，有些团队用了低代码以后会觉得：首版确实做得很快，可只要业务一变，后面还是要不断返工。低代码省下来的时间，最后又花了回去。

问题出在哪里？

低代码能把已经确定的业务规则很快做成系统，却不能替企业把还没想清楚的规则自动想清楚。

如果前面的业务关系没有理清，平台开发得越快，返工也可能越快。

那么，通过低代码平台开发一套企业系统，到底应该先做什么、后做什么？哪些地方可以快，哪些地方不能急？

今天，我就用一套售后工单系统，把这件事讲清楚。

一、动手之前，先把“做完”说清楚

先别急着打开设计器。

业务部门说“做一套售后工单系统”，这句话只说清楚了系统大概要做什么，还没有说明这套系统做到什么程度才算完成。

开发之前，可以先用一张交付卡回答四个问题：

1. 谁会使用？客服、售后主管、工程师和仓库各自负责什么？

1. 业务从哪里开始，到哪里结束？工程师填完处理结果就算完成，还是要等客户验收和回访结束？

1. 首版要做哪些内容？报修、派工、上门、备件领用和验收可以先做；保修结算、费用对账和智能排程，要不要放到后面？

1. 做到什么程度才能交付？客服能查进度，主管能调整派工，工程师能在手机上提交服务记录，客户验收退回后可以重新处理，关键修改还能查到记录。

这四个问题看起来不复杂，却决定了后面所有开发工作的边界。

如果业务认为“客户验收完才算结束”，开发人员却把“工程师提交结果”当成交付终点，那么流程做得再快，最后也得返工。

很多返工都不是功能做不出来，而是大家对“做完”理解得不一样。

交付卡的作用，就是让业务和IT先把这个问题说清楚。

二、页面怎么搭，取决于业务对象怎么拆

交付范围确定后，下一步也别急着画首页。

先看这套系统到底要管理哪些东西。

售后服务至少要分清客户、设备、工单、派工记录、服务记录和备件领用记录。一个客户可以有多台设备，一台设备可以产生多张工单，一张工单可能多次派工、多次上门，一次服务也可能使用多种备件。

如果把这些信息都塞进一张表里，首版看起来很省事，后面的问题却会越来越多。

工程师换人，新的名字覆盖了原来的派工人；第二次上门，新的处理结果覆盖了第一次记录；一次用了三种备件，只能全部写进备注，后面既不能按零件统计，也查不清数量和批次。

拆开以后，客户有客户记录，设备有设备档案，每次派工和上门都有自己的记录，再通过关联关系把它们串起来。

页面也会跟着简单下来。客服看工单全程，工程师看自己的待办和设备资料，仓库只处理领料和退料。每个人看到的是同一笔业务中与自己有关的部分。

在织信里，可以用数据表分别承载这些业务对象，用关联记录和关联列表表达它们之间的关系。模型确定后，平台可以生成基础表格视图和表单，再按照不同角色的工作方式调整页面。

这一步做对以后，页面不需要逐张猜。需要哪些视图、表单和操作入口，基本都能从业务关系里推出来。

三、流程图画出来以后，还要补一张状态表

对象拆清楚了，流程才有地方落。

用低代码画一条流程并不难。难的是，每个状态下谁能做什么，做完以后要留下什么记录。

这时候，可以把流程先写成一张状态表：

一张表摆出来，很多原本藏在流程图里的问题就会露出来。

工单暂停以后由谁恢复？客户退回，是直接回到原工程师，还是由主管重新派工？已经关闭的工单能不能修改？重新打开以后，原来的服务记录还算不算数？

这些问题没有确定，流程图画得再完整，也只是把节点连了起来。

答案确定后，再在织信的BPMN工作流中配置任务、分支、退回、超时和自动化动作。每个节点显示哪些字段，允许修改哪些内容，也要跟角色和任务一起确定。

验收权限时，可以依次检查四个问题：能不能进入模块，能看哪些记录，能看和能改哪些字段，能执行哪些动作。

比如，工程师可以填写故障原因，却不能修改客户级别和保修条款；售后主管可以更换工程师，普通工程师不能直接关闭工单。

织信可以从团队、应用、模块、记录、字段和控件等层级配置权限。首版完成后，要用客服、主管、工程师和仓库的真实账号分别测试，不能只拿管理员账号把流程点通。

正常流程跑完，还要再测几个异常：重复报修、已经派出的工单转派、缺少配件暂停、关闭后的工单重开。

企业系统平时最容易出问题的地方，往往就在这些例外里。

四、接口接得越多，项目未必越快

系统内部跑通以后，项目组很容产生下一个想法：既然都做了，不如把CRM、ERP、WMS、企业微信和财务系统一起接上。

看起来很完整，项目却可能从这里开始慢下来。

客户编码以CRM为准，还是以ERP为准？设备档案由售后维护，还是从资产系统同步？库存接口调用失败以后，是自动重试，还是转给仓库人工处理？同一个客户在两个系统里的名称不一致，又该听谁的？

这些问题不先确定，接口开发得越早，返工也会来得越早。

首版可以优先接两类数据。

第一类，是已经存在唯一权威来源的数据。比如客户和设备资料已经由CRM或ERP统一维护，新应用里再建一份，很快就会出现重复和不一致。

第二类，是一旦录错就会连续影响后续业务的数据。比如保修状态判断错了，可能影响派工、备件领用和费用结算；库存数量错了，工程师到了现场才发现没有配件。

至于使用频率低、业务口径还没定清的能力，可以暂时保留导入或人工核对。等流程稳定、数据责任明确以后，再改成实时接口。

织信可以通过API、自动化、脚本或外部数据源与其他系统交换数据。但平台能把接口做出来，客户、设备和库存到底以哪个系统为准，仍然要由企业确定。

接口开发之前，先定数据来源。这个顺序一旦反了，连接的系统越多，后面越难改。

五、AI可以先搭骨架，工程化决定后面好不好改

看到这里，可能有人会问：前面这些工作都要做，低代码和AI到底快在哪里？

快在确定规则以后，不需要每次都从页面、数据库和基础代码重新做起。

在织信里，项目组可以先向AI描述交付卡、业务对象和流程关系，让AI协助创建数据表和工作流骨架。原来需要反复搭建的基础结构，可以先生成一个能讨论、能修改的版本。

接下来，由业务负责人和实施人员确认字段、状态、权限和异常处理。AI生成初稿，企业确认业务规则，项目组再把这些规则落实到数据模型、流程、权限和运行环境中。

业务以后发生变化，也不用直接在生产系统里边改边试。

项目组可以先在测试环境调整数据表、工作流、自动化或脚本，验证通过后再发布。环境变量可以区分测试和生产的接口地址，基于Git的版本管理可以记录配置变化，需要时再回退到之前的版本。

这就是织信所强调的工程化。

它不能保证AI永远不犯错，却能让AI生成的内容继续受到数据模型、权限、测试环境、版本和发布流程的约束。一次修改出了问题，项目组知道改了什么、在哪里验证，也有机会退回到原来的版本。

对企业应用来说，这种可修改、可检查、可回退的能力，比单独生成一批页面和代码更重要。

六、把快速开发分成五轮，每一轮都要有结果

如果把前面的方法放进真实项目，可以按五轮推进：

这五轮可以反复迭代，也不要求每个项目投入相同的时间。一个部门级应用和一套ERP、MES类核心系统，交付周期不可能一样。

但它们都绕不开几个问题：准备做什么，数据怎么组织，业务怎么流转，谁能做什么，怎样与现有系统共存，业务变化以后又该怎么改。

低代码平台降低了这些问题的实现成本，让业务人员、IT和实施团队可以围绕同一个可运行版本讨论。可客户数据以哪里为准，谁可以重开工单，缺配件算不算超时，仍然要由企业自己决定。

看到这里，再回到开头的问题。

通过低代码平台快速开发，有一个很容易被忽略的前提：需要企业判断的事情，要先有人作出判断。

低代码负责把确定的规则更快做成系统，企业负责把规则说清楚。两边都快，项目才会快。

如果企业正准备把售后、项目、供应链或生产协同流程做成应用，可以先用这五轮清单整理一个业务场景，再让织信AI生成首版骨架。

点击阅读原文，可申请体验织信Informat企业级AI智能开发平台。