本文核心结论：宜搭、简道云等低代码工具很适合快速验证流程，但当表单数量、审批规则和数据复用越来越多时，企业需要重新设计审批中心和数据中心。迁移不是简单“照搬表单”，而是把散落的流程、权限、主数据和报表重新收拢。
一、客户背景：低代码跑得快，也积累了很多历史包袱
客户是一家 200 人左右的工程服务企业，早期用宜搭快速搭了费用报销、采购申请、合同审批、项目立项、用章申请、客户回访等 40 多个表单。上线初期效果很好，各部门不用再发 Excel，老板也能在手机上审批。
但两年后问题逐渐显现。不同部门各自建表，字段命名、项目编号、客户名称和审批规则不统一。一个项目从立项到采购、合同、付款、验收，数据分散在多个表单里。管理层想看项目毛利、待付款、合同风险时，需要运营同事导出多张表再手工关联。
二、原表单问题：流程能跑，但数据复用和权限管理越来越难
我们先盘点全部表单，把它们按业务对象归类，而不是按部门归类。结果发现问题主要有五类：
- 重复建表：不同部门都有“采购申请”“付款申请”类似表单，字段略有差异，审批规则也不同。
- 主数据缺失：客户、供应商、项目、合同没有统一主档，表单里经常手工输入，导致报表无法准确汇总。
- 审批规则分散：金额、部门、项目类型、合同类型都会影响审批流，但规则写在多个表单里，调整一次要改很多处。
- 历史数据难关联：同一项目在立项、采购、付款和验收表单里没有稳定编号，只能靠名称模糊匹配。
- 权限边界不清：部门负责人能看到哪些项目、财务能看到哪些金额、外部协作人员能否查看附件，都缺少统一控制。
这些问题说明，企业已经从“需要快速上线流程”进入到“需要统一管理数据资产”的阶段。
三、一期范围：不是重做所有表单，而是先建审批和数据底座
一期迁移范围控制在四类高频流程：项目立项、采购申请、付款申请、合同审批。原因很简单，它们共享客户、供应商、项目、合同和金额字段，也是管理层最关心的经营链路。
一期建设内容包括：
- 建立客户、供应商、项目、合同、部门、人员等主数据；
- 设计统一审批中心，按金额、部门、项目类型、合同类型和预算状态匹配审批规则；
- 将四类流程改为同一套编号体系，后续单据必须关联项目或合同；
- 迁移近两年历史数据，保留原附件链接和审批结果，并标记无法自动匹配的数据；
- 建立项目视图，集中查看立项、采购、合同、付款和验收状态。
我们没有承诺一期迁完全部 40 多个表单，而是先迁移对经营分析价值最高、跨部门协作最多的流程。其余低频表单继续保留在原平台，待主数据稳定后再分批处理。
四、上线过程：先清理表单，再迁移数据，最后切换流程
上线过程分为四个阶段。第一阶段是表单盘点，把字段分成保留、合并、废弃和新增四类。比如“项目名称”“项目简称”“工程名称”统一为项目主档字段，历史表单里的不同写法作为别名。第二阶段设计审批规则，把过去散落在表单里的条件抽成规则表，由管理员维护。
第三阶段做历史数据迁移。我们先迁移近 6 个月数据做校验，再扩大到两年范围。对于客户名称、供应商名称无法自动匹配的记录，系统生成待确认清单，让业务负责人一次性处理。第四阶段切换新流程，新旧系统并行一周，确认审批、附件、消息通知和报表没有明显断点后，再把高频流程入口切到新系统。
五、结果指标：审批更稳定，经营数据也能复用
上线后，客户重点看三类结果：
- 高频审批表单从 12 个合并为 4 个核心流程，重复字段明显减少；
- 采购、合同和付款必须关联项目或合同，项目视图可以直接看到已申请、已审批、已付款和待付款金额；
- 审批规则调整从过去逐个表单修改，变成在规则表里维护，减少了因漏改表单造成的审批错误。
在一次月度经营会上，管理层第一次按项目维度同时看到合同额、采购申请、已付款、待付款和验收状态。虽然这些数字还需要财务复核，但已经不再依赖运营同事手工拼表。
六、复盘：低代码迁移要尊重历史，也要敢于收口
这个项目最重要的经验是，迁移不能机械复刻旧表单。旧表单里很多字段是部门临时加的，如果全部照搬，新系统只会继承旧混乱。正确做法是围绕业务对象重建模型：客户、供应商、项目、合同、付款才是核心，表单只是它们的流转方式。
第二个经验是，历史数据不要追求 100% 自动清洗。中小企业历史表格里一定有错别字、别名和缺失字段。我们采用“自动匹配 + 人工确认 + 无法匹配标记”的方式，既保证关键数据可用，也避免项目卡在历史数据清洗上。
七、适合借鉴的企业类型
这个案例适合已经使用低代码平台 1-3 年、表单数量超过 20 个、审批规则经常变化、跨表报表越来越难做的企业。工程服务、项目制交付、贸易采购、连锁运营和内部管理流程较多的公司都可以借鉴。判断是否该迁移，不看表单数量本身，而看三个信号：同一数据是否重复录入，审批规则是否难维护，老板想看的经营数据是否必须靠人工拼表。
