应用场景示例：多角色审批流程的软件开发取舍与实施
下面整理的是一个需求示例，用来展示流程类软件在动手开发之前该怎么拆问题，不代表已经完成的实际项目。重点不在功能列得多全，而在哪些地方必须提前定死、哪些可以留到后面再说。
场景：审批散落在聊天记录里
设想一家做工业品销售与配套服务的中小企业，日常要走的审批有三类：报价申请、备件采购、费用报销。节点通常三到五个，规则也不复杂，但触发条件多、参与角色多、异常情况多。报价要经商务核算、财务核价、销售总监确认，金额过线再加一道总经理；备件采购要关联库存与项目编号；费用报销则按部门和额度分岔。
眼下的做法是邮件加微信群。单据版本散在多个对话框里，审批人出差就卡住，事后想查“谁在第几步同意了、当时的附件是哪一版”，只能翻聊天记录。问题不在于缺一个系统，而在于流程本身没有被完整描述过一次——很多分支只有具体经办人心里清楚。
先定边界，再谈功能
这类项目最容易走偏的地方，是一上来就讨论待办列表长什么样。更有效的顺序是先回答四个判断：
- 流程节点是否经常变。一年内节点和条件基本不动的，用代码写死流程更省事，排查也直接；如果业务部门每季度都要调一次审批人规则，就得考虑把流程定义抽出来做成可配置，代价是配置界面本身也要开发和维护。
- 表单字段固定还是自由。字段自由增减听起来灵活，但校验规则、报表口径、历史数据兼容都会跟着变复杂。常见做法是先固化两三条高频表单，把低频的留在后面按需增加。
- 谁在什么设备上操作。填单的人多在办公室，字段多、需要上传附件，PC 端更合适；审批动作则常常发生在路上，移动端只保留查看、同意、驳回、加签几个动作，反而更容易推行。
- 和历史数据怎么衔接。已在进行中的单据要不要导入，导入后按旧规则还是新规则走，这一步不定，上线时一定返工。
把这些写成两三页纸的流程图和规则表，比画十几张界面草图更有用。
方案大致由几块拼起来
按上面的判断，一套轻量的审批系统通常包含以下几层，层与层之间的接口要早一点约定：
- 组织与权限。人员、部门、角色从已有账号体系同步，避免两处维护。审批人解析要支持“直属上级”“部门负责人”“指定角色”这几种取法，并明确取不到人时怎么办。
- 表单与流程定义。字段、必填校验、金额阈值和其他条件分支，与流程节点分开描述，便于单独调整。
- 流程运行。待办、已办、转办、加签、撤回、驳回后重提，以及超时提醒。这些动作看着琐碎，却是实际使用中出问题最多的地方。
- 留痕与查询。每一步的操作人、时间、意见、附件版本都要落库，能按单据号和时间段检索。
- 通知。选一个主通道推送待办，再用邮件或站内消息兜底，避免只依赖单一渠道导致漏看。
实施的推进顺序
分期上线比一次性全量切换稳妥，尤其是第一次把线下流程搬到线上时。
- 流程盘点：把三类审批的节点、条件、异常情形逐条写出来，让经办人确认，这一步的产出是一张覆盖分支的流程图。
- 确定首期范围：挑一到两条高频、规则清楚的流程先做，其余留到第二期。
- 原型与字段确认：把填单页、审批页、列表页走一遍，重点确认字段口径和必填项。
- 开发与联调：先打通账号与组织同步，再跑流程主干，最后补通知与导出。
- 试运行：新旧方式并行一段时间，比对同一批单据两种路径的结果是否一致。
- 正式切换与培训：培训内容以“遇到驳回怎么办、加签给谁、找不到待办去哪看”为主，比讲功能菜单有效。
验收时容易被跳过的几处
界面观感通常第一轮就有人提意见，反而是下面这些边界情况没人主动测，需要写进验收清单：
- 金额正好等于阈值时走哪条分支，阈值变更后历史单据如何计算。
- 审批人离职、长期休假或岗位空缺时，流程是自动上移、转给代理人，还是直接停滞。
- 驳回后重新提交，是回到发起人重走全部节点，还是从被驳回节点继续。
- 同一个人在同一流程中出现两次，是否自动跳过，避免自己审批自己。
- 并发操作：两个审批人同时处理同一张单据时的结果。
- 报表数字与单据明细是否对得上，导出文件在常用表格软件中打开是否正常。
另外，留痕数据要能导出、能按时间归档，否则运行半年后会变成新的黑箱。
交付之后，边界先讲清楚
流程类系统上线后，最常见的两类请求是修缺陷和加流程。两者在排期和计价上差别很大，交付时最好在文档里写明：程序未按既定规则执行、数据计算错误属于缺陷范围；新增一条审批流程、调整字段口径、改变通知方式，则按新需求评估。约定周期内的技术维护覆盖前者，后者单独排期。这样后续沟通会少很多来回。