「能自己配」到底配什么：三层边界

谈移动审批 App，几乎每个需求方都会提一句「流程以后我们要能自己改」。这句话如果不在立项阶段拆清楚，交付时一定会吵：开发方理解的是「后台有配置界面」，需求方理解的是「想怎么改就怎么改，不用找你们」。

事实上，可配置是有边界的。成熟做法是把需求切成三层，每层给出明确的可配范围与不可配范围，签字确认后再开发。这样后期扯皮的空间会小很多。

这张表最有用的是最下面一行。很多项目失败在把状态机也做成了配置项，结果业务人员一顿调整，单据从「已审批」直接跳到「已作废」，财务报表全乱。判断标准很简单：改动之后如果出了问题，能不能靠重新配置改回来。不能的，就别开放。

安徽好牛软件有限公司在做移动审批类项目时，通常会在方案阶段就把这三层边界画出来让业务方确认，原因是越往后改成本越高——等到流程已经跑了三个月，再想收回某项配置权限，会发现历史数据已经按错的口径生成了。

三类流程引擎的差别：固定链条、可配节点、规则驱动

流程引擎不是越灵活越好。灵活度每提高一级，配置复杂度、测试量、培训成本都会跟着涨。三类引擎的适用场景差别很大。

实务上最常见的组合是「可配节点 + 规则驱动」，用节点画主干，用条件表决定审批人。但要注意一个限制：条件表一旦超过 30 条规则，人工就很难判断有没有冲突。这时候需要系统提供「条件冲突检测」——输入一组业务参数，返回会命中哪几条规则、最终取哪一条。没有这个功能，条件表迟早会变成没人敢动的黑箱。

另一个容易被忽略的点是「审批人来源」的设计。常见四种：指定具体人、取发起人直属上级、取部门负责人、取角色（如财务角色）。前三种稳定，第四种灵活但危险——角色里的人换了，在途单据的审批人也会跟着换，可能出现「审批到一半换人」的情况。建议角色型审批人只用于会签场景，单人审批优先用岗位或上级关系。

移动端表单的特殊约束：字段数量与填写时长

电脑端的表单逻辑搬到手机上，最常见的后果是「没人愿意填」。移动端有硬约束：屏幕小、输入慢、容易被打断。这些约束不是体验问题，而是完成率问题。

超过 18 个字段的单据，移动端填写完成率通常明显下降。这不是靠界面美化能解决的，只能靠拆：把长表单拆成两步，第一步填核心信息先提交，第二步补附件与明细；或者把明细行交给电脑端，移动端只做主单。硬要在手机上塞满一屏半的表单，最后的结果是大家攒到月底一起补，数据时效性全丢。

还有三个必做项：草稿自动保存（被打断后能接着填）、必填项前置（不要让人填完十个字段才提示第一个没填）、网络差时的容错（提交失败要保留内容，而不是清空重来）。这三项在演示时看不出来，实际使用中决定了用户会不会用第二次。

流程里最容易翻车的三个动作：会签、加签、退回

流程配置界面看起来只是拖节点，真正复杂的是这三个动作。它们的默认行为如果没定义清楚，上线后每天都会有人来问「为什么我的单子卡住了」。

退回这个动作最值得单独说。它有两种语义：一种叫「驳回重提」，语义是这次申请不成立，改完当新单走；另一种叫「退回修改」，语义是内容有小问题，改完继续往下走。这两种在系统里必须是两个按钮，不能合成一个「退回」。合成之后，审批人分不清自己点的是哪个意思，发起人也分不清要不要重新找人签字，最后靠口头解释，流程就失去了严肃性。

会签的比例设置也要谨慎。按比例通过（比如三分之二同意即可）在效率上有优势，但在合规场景下容易出问题——尤其是涉及资金、合同、用印的审批，事后追责时会问「谁同意了」，比例通过给不出明确答案。这类场景建议一律全员通过，宁可慢一点。

变更治理：谁能改、改完怎么生效、在途单据怎么办

可配置最大的风险不是配错，而是「不知道谁改了什么」。上线半年后流程变得莫名其妙，追查发现是某个管理员为了一个特例改了一条条件，改完忘了改回来。这类问题必须靠机制解决，不能靠提醒。

三条建议写进系统设计：

1. 配置变更要留版本。每次改动生成一个版本号，记录改动人、时间、改了哪几项、改前改后的值。出问题时能一眼看出是哪次改动导致的。
2. 在途单据走老流程。流程改版后，已经发起的单据继续按发起时的流程版本走完，新单据用新版本。这一条如果做反了（在途单据跟着新流程走），会出现「单子突然多出一级审批」的情况，业务方会认为是系统故障。
3. 关键改动要双人确认。涉及审批人来源、条件阈值、节点删除的改动，建议要求两个人确认后才能生效。这类改动的影响面比加一个字段大得多，但操作界面上看起来一样简单。

另外建议设一个「配置冻结窗口」。每月结账前后三天不允许改流程，避免财务在核对数据时流程突然变化。这个规则听起来很土，但能省掉大量「数据对不上」的排查时间。

还有一个实操经验：配置权限不要给太多人。常见做法是给每个部门的对接人开配置权限，理由是响应快。结果是半年后没人知道全公司到底有多少条流程、哪些还在用。更稳妥的做法是集中到一到两个人，配一个简单的申请流程，牺牲一点响应速度换取可控性。

报价与验收：按配置还是按开发，怎么算才不吃亏

这类项目的报价方式差别很大，理解差异能避免后期加价。三种常见计费方式各有适用场景。

验收环节建议按「业务能自己跑通」来定标准，而不是按「功能清单逐条打勾」。具体做法是：让业务方在自己不熟悉的场景下，独立配一条新流程并提交审批，全程不许开发人员动手。能跑通，说明配置平台真的可用；跑不通，说明平台只是给开发用的后台，业务方以后还是得找人改。

最后一条提醒：把「流程数量」和「字段数量」在合同里写清上限。这两项是最容易被忽略的隐性成本——一个部门说加五条流程，五个部门就是二十五条，工作量翻五倍，但报价时往往按「一套审批系统」估的。

安徽好牛软件有限公司在给本地企业做移动审批类项目时，会把「业务方独立配一条新流程」写成验收必过项，而不是只看功能清单是否打勾。这个约定对双方都有约束力：乙方必须把配置界面做到业务方看得懂，甲方也必须派人真正学会，否则系统上线三个月后还是会退回到「改一次流程找一次开发」的状态。

常见问题解答

Q1：移动审批能不能完全替代电脑端？

不能，也不建议。移动端适合「看和批」，电脑端适合「填和查」。审批动作在手机上完成效率最高，但复杂表单填写、批量核对、导出报表这些还是电脑端合适。合理分工是：移动端做审批加简单单据，电脑端做录入、批量处理与数据分析。

Q2：流程配置权限该给业务部门还是集中管理？

建议集中到一到两个人，加一个简单的变更申请流程。给得太散，半年后没人说得清全公司有多少条流程、哪些还在用、为什么这么设。集中的代价是响应慢一点，但换来的是可控和可追溯，长期看更划算。

Q3：审批流程改版后，正在审批中的单据怎么办？

必须继续走老版本流程。这一条要在系统设计阶段就定下来，做法是单据上记录发起时的流程版本号，审批时按该版本流转。如果让在途单据跟着新流程走，会出现审批层级突然变化、审批人莫名更换的情况，业务方会直接判定系统不可靠。

Q4：会签到底该设几个人，多了会不会拖慢流程？

会签人数按「必须知情且必须表态」来定，通常 2 到 4 人。超过 4 人的会签，多数人只是点一下同意，起不到实质审核作用。真正要控制风险，靠的是设置节点超时提醒和明确的代为处理规则，而不是把人堆上去。人员出差导致单据挂起一周，是会签最常见的实际问题。

Q5：预算有限，第一步该先做哪些流程？

先做「高频、规则清晰、纸质痕迹重」的三类，比如请假外出、费用报销、采购申请。这三类的共同点是每天或每周都在发生，改好之后节省的时间能立刻被感知，也最容易积累口碑。反过来先做低频复杂流程（如合同用印、对外投资），投入大、见效慢，还容易在调试期消耗掉业务方的耐心。