Article
很多制造业老板在推 OA 时，第一反应是员工习惯改不过来、基层不愿意配合、管理要求执行不到位。但真进到系统里看，问题常常不是“人不肯用”，而是流程设计默认每一步都按理想状态发生，角色权限又照着组织架构生搬硬套。结果是一线嫌麻烦，主管嫌绕，行政和 IT 只能不断打补丁，系统最后像是上线了，实际上谁都不愿意把关键流程真的放进去。
发布时间
2026年4月13日
阅读时间
7 分钟
制造与工业
工厂环境和纯办公室场景不一样。班组、车间、仓库、采购、质检、设备、行政，很多流程并不是一条标准审批线，而是会夹着口头确认、临时替班、紧急插单、异常返工和跨部门协同。你如果把 OA 按“表单 + 审批树”硬套上去，看起来很规范，实际却很容易把一线工作越做越卡。
我见过不少项目，需求讨论时大家都说要“把流程线上化”，但真正到上线阶段，最先暴露的问题往往不是功能少，而是节点谁能发起、谁能代办、谁能退回、异常时谁有临时处理权没有说清。流程和权限一旦没拆明白，员工不用只是结果，不是原因。
制造业现场最常见的问题不是没有制度，而是制度落地时会遇到很多例外。请假流程会碰到夜班交接，采购申请会碰到供应商临时缺货，设备报修会碰到维修负责人不在岗，质检异常会牵扯返工和补料。系统如果只允许用户沿着一条最整齐的主线往下走，大家很快就会发现线下沟通更快，于是 OA 只剩下“补录痕迹”的作用。
所以做工厂 OA，第一步不是把表单都搬上去，而是先把哪些环节真的是高频标准动作、哪些环节天然带例外、哪些节点需要保留人工协调空间讲清楚。不是所有线下动作都值得被系统替代，有些更适合被系统记录和追踪，而不是被系统强行指挥。
先分清高频标准流程和高频异常流程
不要用一条审批树试图吃掉所有现场情况
系统该固化的是责任与状态，不一定是每一次沟通动作
很多 OA 项目喜欢直接照着组织架构配权限：主管能看本部门，经理能看全部，行政能发起某些申请。这样做在汇报链条上看着合理，但真实业务往往不是这么运转。比如设备维修可能按产线分工，质检处理可能按问题类型走，采购补单可能需要仓库和计划同时可见，临时代理班长又会在某个时段拥有部分审批权。组织结构不等于业务权限，直接照抄，系统很快就会出现“该看的人看不到，不该卡的节点被卡住”的问题。
更稳的做法是把权限拆成几个维度：谁能发起，谁能查看，谁能编辑，谁能审批，谁能处理异常，谁能在什么条件下临时接管。权限一旦按动作和场景拆，而不是只按部门头衔拆，后面很多推广阻力会小很多。
组织架构只能提供参考，不能直接等于系统权限模型
权限要按动作、场景、时间段和例外条件去拆
代办、转交、临时接管这些能力，工厂场景往往不是可选项
很多工厂做 OA，容易一开始就列出一长串清单：请假、报销、采购、维修、入库、出库、质检、宿舍、用车、访客、印章……看起来很完整，实际上每多一条流程，就多一轮培训、例外处理和权限纠缠。如果基础模型还没跑顺，一次全上通常只会放大混乱。
我更建议先选 1 到 3 条最关键、最能体现协同价值、同时又有相对清晰责任链的流程。先把发起、审批、异常、催办、统计和移动端使用习惯跑顺，再决定下一批流程怎么扩。OA 推广真正需要的不是“功能表很长”，而是让一线觉得这套东西不会给他们添堵。
工厂 OA 推不下去，常见根因不是员工排斥系统，而是流程设计把真实现场想得过于理想化。
权限如果只按组织架构照抄，往往会比流程问题更早把系统拖成负担。
一期先跑通少数关键流程和异常处理机制，比一次搬上所有流程更容易真正落地。