When Coordination Runs on Inboxes and Spreadsheets
A purchase order needs approval from three people, so someone sends an email. A quality hold requires a decision from production and the customer service team, so someone makes a phone call. A shipment exception needs a response before the carrier window closes, so someone texts a manager. None of this is unusual, and none of it is invisible. The cost shows up as delay, rework, missed commitments, and the quiet overhead of people spending their day chasing status instead of doing the work.
The instinct is to automate. Buy a workflow tool, extend the ERP, build a dashboard, connect a few systems. Automation encodes whatever process it finds. If the process is unclear, ownership is undefined, or the underlying data is unreliable, the automation makes those problems faster and harder to unwind.
The question worth answering first is not which tool to use. It is whether the process is actually understood well enough to encode.
Why the Architecture Breaks Before the Technology Does
Work that crosses a functional boundary, a system boundary, or a decision boundary tends to fall into informal channels because no one has formally defined what should happen there. The inbox and the spreadsheet are not the cause of the problem. They are the symptom of a process that was never fully designed.
The same dynamic plays out in business processes. When the escalation path for an exception is not defined, and when the record of what happened lives in someone's inbox rather than a system, the process cannot be governed, measured, or improved.
NIST's Advanced Manufacturing Data Infrastructure and Analytics program frames the broader challenge: turning data into meaningful intelligence is difficult, and technologies are seldom one-size-fits-all solutions. That observation applies directly to workflow and automation decisions. The technology is not the hard part. The hard part is establishing the structure, context, and ownership that make the technology useful.
Separate What You Are Actually Designing
Before encoding anything in a system, a manufacturer needs to distinguish between several things that are easy to conflate.
A policy is a rule the business has decided to follow: all purchase orders above a certain value require a second approval, or no shipment leaves without a signed quality release. A business rule is the specific condition that triggers an action: if the order total exceeds a threshold, route it to the operations manager. A decision is a judgment call that requires a person: whether to accept a partial shipment from a supplier given current inventory and customer commitments. A work step is a task someone performs: entering a receipt, updating a status, sending a confirmation. A system transaction is what the software records when the work step is complete.
These are not the same thing, and automating one does not automatically handle the others. A workflow tool can route an approval request and record the response. It cannot make the decision for the approver, and it cannot substitute for a policy that was never written down. If the policy is ambiguous, the workflow will surface that ambiguity at scale, on every transaction, until someone resolves it.
The same discipline applies to process design. Define what each step produces, who owns it, and where the record lives before deciding how to automate the handoff.
Define Ownership Before Defining the Workflow
A process that touches procurement, production, quality, and customer service may have four teams who each believe someone else is accountable for the exception. When the exception arrives, it sits.
A practitioner writing in IndustryWeek about implementations at Ford Motor Company and Mopec Group concluded that the gap between a working automation and a useful one is entirely human. The same is true of a process step. If no one is accountable for resolving a supplier discrepancy, no workflow tool will resolve it. The tool will route the notification. The notification will age. The discrepancy will persist.
That same practitioner notes that if a metric is not owned by any team or individual, it will become obsolete sooner or later. Ownership has several distinct components that are worth separating. The source of a signal, such as a quality system flagging a nonconformance, is not the same as the steward of the record, the person authorized to make the decision, or the person responsible for escalation when the decision is not made in time. Those roles may sit with different people. Defining them is a design decision, not a departmental assumption.
For normal work, the design question is: who does what, in what sequence, and what record does each step produce? For exceptions, the design question is: who decides, by when, and who escalates if they do not? Both questions need answers before a workflow is built.
Approaches Worth Comparing
Once the process is understood, the response does not always require a new platform. Several approaches are worth evaluating against the actual problem.
Extending an existing system is a reasonable starting point when the process already lives primarily in one application. An ERP, a quality management system (QMS), or a customer relationship management (CRM) platform may have workflow or approval capabilities that are underused.
Targeted integration addresses the case where two systems need to exchange a specific record or event without a person in the middle. A production status update that should trigger a customer notification, or a supplier acknowledgment that should update a purchase order, may not require a workflow platform at all. The tradeoff is that point-to-point integrations can multiply and become difficult to govern as the environment grows.
Reporting and portal patterns are appropriate when the problem is visibility rather than routing. If the real issue is that a manager cannot see exception status without calling three people, a dashboard or a permissioned portal may solve it without changing the underlying process. The tradeoff is that visibility does not resolve an exception. It only surfaces it faster. If ownership and escalation paths are not defined, better visibility accelerates the discovery of the same unresolved problem.
A governed workflow and exception automation implementation makes sense when the process genuinely crosses multiple systems and functional owners, when exceptions require tracked decisions and audit trails, or when the volume of coordination work has outgrown what informal channels can handle. Camunda, in a sponsored article, describes process orchestration as providing the connective tissue between people, systems, and devices, coordinating handoffs and scaling from prototype to production. The tradeoff is implementation effort, ongoing governance, and the discipline required to keep process definitions current as the business changes.
None of these approaches is universally correct. The right choice depends on where the process actually breaks, how many systems and owners are involved, and whether the underlying policies and ownership are clear enough to encode.
The Tradeoffs That Determine Whether It Works
A workflow that routes a purchase order for approval needs a reliable order record. A dashboard that surfaces quality exceptions needs consistent data from the systems that generate them. In the context of industrial data governance for manufacturers, Automation World notes that AI and analytics tools are only as useful as the data foundation underneath them. The same principle applies to workflow automation: if the source data is inconsistent, the workflow will route incorrect information with the same efficiency it routes correct information.
Data quality deserves attention as an implementation constraint that is easy to underestimate. A practitioner perspective published in Automation World on industrial data governance observes that, in industrial automation system design, many data problems start much earlier, during automation design rather than after the system is deployed. The underlying pattern is worth considering for business process work as well: addressing data structure, ownership, and system boundaries before encoding a workflow reduces the risk of building automation on a foundation that cannot support it.
Adoption is the second constraint. A system that engineers work around rather than through produces unreliable data and undermines the decisions that depend on it. Adoption is not a launch event. It is an ongoing operating discipline.
Process orchestration approaches also carry different governance requirements. According to Camunda, deterministic workflows, where logic and routing are predefined, offer a high degree of predictability and control and are auditable by design. That predictability depends on rules being written down clearly before implementation begins. Camunda notes that more dynamic approaches incorporating AI-assisted routing or exception handling offer flexibility, but that without oversight, agents can deviate from business objectives or create unpredictable outcomes. For most manufacturing coordination work, the rules are knowable. The discipline is writing them down before encoding them.
Where to Start
The practical sequence is not complicated, but it requires resisting the pull toward tooling before the design work is done.
Begin with the customer or operating outcome, not a departmental task list. A purchase-to-pay process exists to ensure that the right materials arrive on time and that suppliers are paid accurately. A quality release process exists to ensure that nonconforming product does not reach the customer. Starting from the outcome makes it easier to identify which steps are necessary and which exist because no one redesigned the process after the last system change.
Map the end-to-end flow across the functions and systems involved. Identify where records are created, where they cross a boundary, and where they are consumed. Note where the flow depends on a person-to-person handoff that has no system support, and where exceptions currently go unresolved or get resolved informally.
For each step, separate the policy from the decision from the work step from the system transaction. Assign an accountable owner for normal work and a defined escalation path for exceptions. If ownership is genuinely contested, that is a governance decision the business needs to make before any system can enforce it.
Establish a measurable baseline before implementing anything. Measuring cycle time, exception volume, and resolution time before implementation gives the business a way to evaluate whether the change worked and where to improve next.
Finally, select the smallest response that addresses the actual problem. Not every coordination failure requires a new platform. Some require a clearer policy. Some require a single integration. Some require a dashboard that surfaces what is already in the system. Reserve a full workflow and exception automation implementation for the cases where the process genuinely crosses multiple owners and systems, the rules are clear enough to encode, and the volume justifies the governance overhead.