A plant can have two versions of a workflow. There is the one in the work instruction. There is the one that runs on the floor, carrying things nobody wrote down: the rush order that skips a step because it always has, the customer who gets different terms, the scheduling call one person is trusted to make.

Automation projects get scoped from the documented version and deployed into the other. And that gap is where projects stall. The system does what the spec said. The undocumented exceptions keep moving through the same people as always, because nobody put them in the spec. The plant runs the new system and the old workarounds side by side, with someone reconciling them by hand.

Take one exception—a scheduling or pricing call a single person is trusted to approve. Often nothing about it is written down: not the conditions that trigger it, not who else is aurhotized to approve it, not how far it can go. Automate around that exception and it does not disappear. It moves into email or a side spreadsheet, and the automated path now has an undocumented bypass.

These problems can be surfaced before a vendor scopes the work. Run a tabletop walkthrough, away from the equipment with nothing operating. Deliver the written procedure for one critical workflow to a capable employee who does not normally run it and have them talk through it step by step, while the usual owner listens without coaching. Note every point where they stop, ask a question, hunt for a file not identified in the procedure, or need approval no document grants.

Those gaps belong in the requirements document. Define how each exception should be handled, who can approve it and what limits apply. Then scope the automation around that clarified workflow.

Brad Berlin, founder, Berlin Management Group