做工厂 OA 或内部审批系统时，我不太会先判断“员工是不是不配合”。很多系统上线后没人爱用，表面看是培训没做好、执行不到位，实际往往是系统把现场工作想得太标准了。
办公室里的审批流程，很多时候可以按部门、岗位、审批层级往下拆。但工厂现场不一样，班组、车间、仓库、采购、质检、设备、行政之间，经常夹着临时插单、夜班交接、设备抢修、异常返工、代班处理。你如果只做一棵很规整的审批树，页面看起来很完整，现场用起来反而会很卡。
先分清标准流程和真实流程
OA 项目里一个常见误区，是把制度文件里的标准流程直接搬进系统。比如请假、报修、采购、质检异常，每条流程都画得很顺，但真实执行时一定会有例外。
更稳的做法，是先把流程分成三类：
-
高频且稳定的动作，可以固化成标准流程
-
高频但经常有例外的动作，要预留退回、转交、代办和备注
-
低频且变化很大的动作，不一定第一期就强行系统化
系统最该固化的不是每一句线下沟通，而是责任、状态和结果。否则大家最后会形成一个很尴尬的习惯：事情在线下聊完，系统只负责事后补记录。
权限不要只照抄组织架构
另一个容易踩坑的地方是权限。很多项目一开始会说，主管看本部门，经理看全部，行政能发起流程，听起来没问题，但真实业务经常不是按组织架构跑的。
设备维修可能按产线分工，质检异常可能按问题类型处理，采购补单可能需要仓库和计划同时可见，临时代班的人又可能只在某个班次拥有审批权。如果权限只按“部门 + 职级”做，很快就会出现该处理的人看不到、不该卡住的节点被卡住。
我更倾向于把权限拆成动作和场景：谁能发起，谁能查看，谁能编辑，谁能审批，谁能转交，谁能在异常情况下临时接管。权限模型拆细一点，后面推广阻力反而会小很多。
一期别把所有流程都搬上去
工厂 OA 最怕第一期就追求“大而全”：请假、报销、采购、维修、入库、出库、质检、用车、访客、宿舍、印章全部一起上。功能清单看起来很有成果，但每多一条流程，就多一套权限、通知、异常和培训成本。
如果基础流程模型还没跑顺，一次全上只会把混乱放大。我一般更建议先选 1 到 3 条最关键、最能体现协同价值、责任链又相对清楚的流程。先把发起、审批、催办、异常处理、统计和移动端使用习惯跑通，再扩第二批。
OA 真正能推下去，不是因为功能表很长，而是因为一线发现它没有额外添堵，管理层也能看到真实状态。能做到这一步，比第一版就做几十个流程更重要。
我把这个判断整理成了一篇更完整的文章： sphrag.com/zh/blog/fac…
