40 多位零基础业务人员，30 天搭了 500 多张表单

车企事业部多，大量审批还是纸单，有的事业部既没有数字化部门也没有技术人员。这家整车集团的做法是三套平台、16 个租户按事业部隔离，简单场景交给自己搭。本文给出可放开的四类场景白名单、模板与差异的切分方式，以及每张表单上线前的验收动作。

纸单卡住的是三件事

审批走不动。纸单要人签字，领导出差两天，单子就在办公桌上放两天。

时长不可控。纸单缺少提醒，没人知道这张单子在谁手上停了多久，催的方式是打电话。

统计靠手工。纸单能改、容易丢，月底要做分析，得有人把一摞单子逐张录一遍。填报不规范的还要来回改，改完的原单和补的单子是不是同一件事，只能靠人记。

这三件事在纸单形式下没有解法，加人手也只是把录入的速度提快一些。

没有技术人员的事业部谁来搭

这家集团用 Dolphin Code 低代码平台建了三套平台、16 个租户。租户按事业部切，各事业部在自己的租户里搭应用、管数据，互不干扰。

分工是这样划的：填表、签到、登记、汇报这类简单场景，事业部自己搭；涉及跨系统取数、涉及集团统一口径的，交给集团的信息部门配。业务人员不需要会写代码，需要会的是把自己那张纸单的字段和审批顺序说清楚。

审批在电脑和手机上同步走，有待办提醒，填写时就规范输入。纸单上的空格可以不填，线上表单可以设成必填、可以限制选项和格式，填报不规范的问题在入口就挡住了。

CREATE TABLE form_definition (
  form_id       VARCHAR(32) PRIMARY KEY,
  tenant_id     VARCHAR(32) NOT NULL,   -- 事业部，数据与权限按租户隔离
  template_id   VARCHAR(32),            -- 复用来源，空表示自建
  form_name     VARCHAR(128) NOT NULL,
  category      VARCHAR(16)  NOT NULL,  -- FILL / SIGNIN / REGISTER / REPORT
  approval_max  TINYINT      NOT NULL,  -- 审批链层级，超过 3 级先不放开
  field_schema  JSON         NOT NULL,  -- 必填、选项、格式约束
  owner_user    VARCHAR(64)  NOT NULL,  -- 责任人，落到人名
  accept_by     VARCHAR(64),            -- 验收人，为空不算上线
  accept_at     DATETIME,
  status        VARCHAR(16)  NOT NULL   -- DRAFT / ACCEPTED / ONLINE / OFFLINE
);

tenant_id 与 template_id 要同时存在。前者决定数据边界，后者决定这张表单能不能跟着集团模板升级。只有 tenant_id 的平台上，500 张表单会变成 500 个孤岛；只有 template_id 的平台上，一个事业部的字段改动会污染其他事业部。

500 多张表单是怎么来的

有个事业部组织 50 多人学低代码，其中 40 多位是零基础的业务人员，30 天搭了 500 多张无纸化表单，全部验收完成。现在有 11 个事业部能自己搭应用。

把 500 多张摊到 30 天、40 多人头上，平均每人每天不到一张。这个速度主要来自表单本身高度重复：同一类请假、领用、签到，各事业部拿同一个模板改字段和审批人。省时间的地方在模板，不在手速。

需要提醒的是验收这一环。这 500 多张是全部验收完成之后才计入成果，没验收的表单不算上线。业务人员自己搭的应用最容易出的问题就是没人验收，跑三个月发现审批人和实际责任人对不上。

流程走向：

• 集团模板：请假 / 领用 / 签到 / 汇报 → 事业部改字段与审批人
• 事业部改字段与审批人 → 校验
• 校验 →（审批链 > 3 级）退回，先不做
• 校验 →（属于放开场景）事业部负责人签字验收
• 事业部负责人签字验收 → 上线，责任人写入应用信息
• 上线，责任人写入应用信息 → 月度复查：填写量、退回率、审批时长
• 月度复查：填写量、退回率、审批时长 →（三个月无人填写）下线

哪几类表单适合交给业务自己搭

交给业务自己搭	原因
填表、签到、登记、汇报	字段少，审批链短，错了不牵连别的系统
领用、借用登记	数据在本部门内部用
检查、巡查记录	要手机填报，要按人限权

先别交给业务	原因
涉及对外合同和价格	填错有法律和财务后果
要写回 ERP 或财务	接口和口径得由专业部门管
集团统一口径的报表	各家自己改字段，汇总就散了

这两张表要贴在培训材料的第一页。业务部门的积极性是好事，把不该开放的场景也搭起来，后面收场的成本更高。落到配置上就是白名单：category 只允许四类取值，超出类别的表单无法提交验收。

上线之后看到的变化

审批更及时，因为待办会提醒，手机上就能批。留痕可追溯，谁提交、谁审批、改过什么都在系统里。业务变了改配置就能跟上，不用重新走一遍需求。

这三条对事业部来说是日常感受，对集团来说还有第四层：以前每个事业部一套纸单，集团拿不到统一口径；现在表单结构在平台上，集团想看某一类审批的总量和平均时长，能直接取数。

可以照搬的三步

1. 先挑一个事业部试点，挑纸单量最大、又没有技术人员的那个，这类事业部最有动力。
2. 只放开四类场景：填表、签到、登记、汇报。审批链不超过三级，超过三级先不做。
3. 每张表单上线前由事业部负责人签字验收，责任人写进应用信息里。

上线检查清单

• 租户按事业部切分，跨租户查不到别人的数据
• 表单类别受白名单约束，合同价格与写回 ERP 的场景不在业务侧
• 审批链层级超过三级的表单被配置校验拦住
• 模板字段与事业部附加字段分开，改附加项不影响集团汇总
• 每张上线表单有验收人和验收时间，缺项状态不为 ONLINE
• 责任人写到人名，应用信息页可见
• 有三个月无人填写的自动复查与下线动作
• 各事业部在用的纸质表单数量已按"一天走几张、几个人签字"排序

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中表结构与流程为示意。