Why factory OA rollouts often stall: not because people resist, but because the system was built as a shell

Many factory approval flows look clean at a high level, but daily execution is full of exceptions. A normal material purchase and an urgent replenishment request do not follow the same path. Advance payment, final payment, reimbursement adjustment, and after-sales compensation often require different handling as well. If the system only supports the ideal “main path,” users return to chat, calls, and paper the moment an exception appears.

That is what I mean by shell development. The project copies form fields into a screen without truly redesigning the workflow. The interface looks digital, but the operating model has not changed. Instead of replacing manual coordination, the system creates another layer of explanation and re-entry work.

Many OA projects mix together who initiates, who approves, who needs visibility, who executes, and who archives. On paper that sounds transparent. In practice it often means everyone clicks more, reads more, and explains more. For an office team that is annoying. For production, warehouse, or procurement staff, it becomes a direct reason to bypass the system.

A steadier design gives each role a lighter surface. Initiators care about complete submission, approvers care about enough context to decide, executors care about next actions and state change, and managers can look at summaries separately. If every role must open the same heavy interface, the product becomes both slower and less usable.

Another common pattern is that management says they want OA, but what they really want is to fix unclear ownership, cross-team conflict, inconsistent data, and weak process decisions. Software can support those issues, but an approval platform cannot heal them by itself. If the project starts with the expectation that the system will also reorganize the company, the scope gets heavy very quickly.

A better move is to narrow the goal. Pick one painful, measurable, and standardizable loop first, such as purchase approval, payment request, or exception feedback handling. Let the system genuinely replace the old method in one scenario before trying to unify every collaboration path. OA is good at transparency and traceability. It is not a substitute for management judgment.