Many process models look convincing until the factory encounters a serious abnormal condition.
A machine develops unusual vibration. Quality detects dimensional drift. Production is already behind schedule. Maintenance requests access to the equipment. Logistics warns that the next customer sequence will be difficult to recover if the line stops.
At that point, a deceptively simple question emerges:
What is the process?
Is it the maintenance process? The quality containment process? The production recovery process? The escalation workflow? The deviation-management process?
In practice, it is all of them simultaneously.
This is where workflow-centric BPM begins to reach its limits.
The problem is not necessarily that the organisation has failed to document enough processes. The deeper issue is that industrial operations frequently create situations in which several processes, objectives, systems and decision rights converge around the same physical event.
A workflow can describe the expected route.
The factory must also govern what happens when the correct route cannot be determined in advance.
One Physical Process, Several Operational Logics
Production, maintenance and quality operate around the same equipment and production process, but they interpret operational reality through different lenses.
Production is primarily concerned with flow, schedule attainment, takt, throughput, constraint management and recovery.
Maintenance evaluates equipment condition, failure probability, technical uncertainty, intervention requirements, spare-part availability, access windows and long-term asset reliability.
Quality concentrates on conformity, containment, traceability, process capability, customer exposure and evidence that the production process remains under control.
None of these perspectives is inherently superior.
The difficulty appears when process design implicitly assumes that one perspective can become the master workflow while the others are treated as supporting activities.
Serious operational abnormalities rarely behave in that way.
Consider a machining operation in which a critical dimension begins moving towards a control limit while spindle vibration is also increasing.
Production may reasonably argue that the process is still producing conforming parts.
Quality may reasonably question whether continued production is increasing the population potentially requiring containment.
Maintenance may know that an intervention now would permit a controlled inspection, whereas another two hours of operation could convert a manageable bearing issue into a more significant failure.
The organisation does not simply face a sequence of tasks.
It faces a decision situation involving competing operational objectives, incomplete information and changing risk.
That distinction is fundamental.
Workflow Logic Works Best Where the Next Step Is Predictable
Structured workflows are indispensable in industrial organisations.
Preventive maintenance execution, calibration, material release, procurement, engineering change control, approval processes and many other activities benefit from defined sequencing, standard roles and disciplined execution.
The problem begins when the same design logic is extended to work that is inherently contextual.
A conventional workflow assumes that, given the current process state, the next activity can largely be determined in advance.
Abnormal industrial events frequently violate that assumption.
When a significant deviation occurs, the next action may depend on information that did not exist when the process was modelled.
Is the equipment genuinely degrading, or is the condition-monitoring signal misleading?
Have suspect units already progressed downstream?
Can production move to another asset?
Is the required technician available?
Does maintenance have the necessary spare?
What is the potential customer exposure?
Can the problem be contained while production continues?
Has the same failure mode occurred before?
Is there an approved temporary countermeasure?
Most importantly, who has the authority to accept the residual operational risk?
If every possible combination is encoded into a workflow, the model becomes increasingly complex and difficult to maintain.
If it is not encoded, employees inevitably begin making decisions outside the prescribed route.
Management may then conclude that people are failing to follow the process.
Sometimes that diagnosis is correct.
In other cases, however, the process design itself is attempting to eliminate uncertainty by modelling it as if it were predictable.
Exceptions Are Part of the Operating Model
A persistent weakness in process management is the assumption that the documented flow represents the real process while exceptions exist somewhere outside it.
On the shopfloor, the opposite may be true.
The normal production cycle can be highly standardised, yet a disproportionate share of operational risk and management attention is concentrated in abnormalities: repeated micro-stops, unexplained quality drift, deteriorating equipment, missing material, failed restarts, temporary repairs, inspection disputes and deviations from standard work.
These situations expose the organisation’s real operating model.
Who becomes involved?
Which information is considered authoritative?
Who can stop production?
Who decides whether continued operation is acceptable?
Under what conditions can a temporary countermeasure be used?
When must a local problem be escalated?
Who has authority to release equipment or product?
How is the decision rationale preserved so that the following shift does not reconstruct the same situation from fragments?
A conventional process map may describe activities.
It does not necessarily define decision rights, evidence requirements and accountability under uncertainty.
That is the domain of operational governance.
During an Abnormality, the Unit of Management Changes
When maintenance, quality and production confront a significant abnormal condition, the operational unit being managed is no longer simply a work order, a quality record or a production event.
It becomes a shared operational case.
The case has an objective: restore a safe, capable, reliable and controlled operating condition.
However, the route towards that objective evolves as evidence changes.
Maintenance may inspect the asset and eliminate the suspected mechanical cause.
Quality may subsequently identify a correlation with a particular material batch.
Production may discover that the pattern began after a changeover.
Engineering may then need to become involved.
The appropriate sequence emerges progressively because the diagnosis itself is evolving.
This does not imply abandoning standardisation.
Adaptive work actually requires strong discipline around a different set of questions:
What is the current operational condition?
What evidence supports the present diagnosis?
What uncertainty remains?
Which decisions have been made, and by whom?
Who owns the next action?
What risk has been explicitly accepted?
What conditions must be satisfied before normal operation can resume?
The route may be adaptive.
Accountability cannot be.
The Factory Does Not Need Forty Disconnected Workflows
Functional process optimisation creates another problem.
Maintenance manages its work in the CMMS or EAM.
Quality records deviations, inspections and containment in the QMS.
Production execution and equipment status are captured through MES or MOM.
Escalation may occur through meetings, email, messaging platforms, Andon systems, spreadsheets or visual management boards.
Each system can perform exactly as designed while the overall operational response remains fragmented.
The maintenance record confirms that the asset was inspected.
The QMS confirms that material was contained.
MES records downtime and production history.
Production planning records schedule loss.
Yet the organisation may still lack a coherent operational narrative explaining what happened, why particular decisions were made, which risks were considered, what evidence justified restart and whether the corrective action actually removed the underlying condition.
This should not automatically be classified as an IT integration problem.
It is often a process-governance problem expressed through fragmented systems.
Integration is important because operational decisions require reliable context.
But information availability and decision authority are not the same thing.
An interface between MES and CMMS can exchange machine status, downtime events and work-order information.
It cannot decide whether production should continue.
A QMS workflow can enforce containment activities.
It cannot independently determine whether maintenance evidence is sufficient to release equipment back to production.
An API can connect systems.
It cannot resolve conflicting operational objectives or define who has the right to accept risk.
Those are governance questions.
Standardisation and Adaptation Are Not Opposites
There is an opposite mistake that should also be avoided.
Once organisations recognise that operations are complex, they sometimes conclude that structured workflows and standards are obsolete.
They are not.
Stable work should remain stable.
A preventive maintenance route should not become an improvisation exercise.
A defined quality-containment requirement should not depend on personal preference.
Safety controls must remain mandatory.
A controlled restart should require explicit conditions.
Traceability requirements should not disappear because the situation is unusual.
The more useful design principle is to distinguish between the predictable spine of the process and the adaptive layer required to manage uncertainty.
The predictable spine establishes mandatory controls, standard roles, minimum evidence, escalation thresholds, decision authority, release criteria, prohibited actions and traceability requirements.
The adaptive layer determines the appropriate next action according to the actual operational condition.
This is not a compromise between process discipline and improvisation.
It is a more mature form of process discipline.
It recognises that some aspects of execution should be standardised precisely, while others require controlled professional judgement within explicit governance boundaries.
A Practical Example: The Line Can Continue, but Should It?
Consider a production line experiencing intermittent torque anomalies during a critical fastening operation.
The station has not failed.
Most units remain within specification.
Production is already under pressure because the shift began with an unrelated material shortage.
Maintenance sees evidence that the fastening tool may be deteriorating but cannot confirm the mechanism without stopping the station.
Quality identifies several borderline results and requests additional verification.
A conventional functional response is easy to predict.
Production wants to preserve output.
Quality wants to reduce potential exposure.
Maintenance wants an intervention window.
Each department may follow its own process correctly.
The factory can still lack a mechanism for making the combined operational decision.
A more mature model would establish a shared operational case around the abnormality.
MES could provide production history, cycle information, parameter behaviour and the timing of the anomaly.
Quality could contribute inspection results, conformity information, product genealogy and the definition of the potentially affected population.
Maintenance could add tool history, previous interventions, alarms, condition evidence and its assessment of failure risk.
Production planning could make visible the consequences of stopping immediately, stopping later or transferring work.
These data sources do not eliminate uncertainty.
They create the evidence base required to manage it.
The cross-functional team must then evaluate real alternatives.
Should production continue temporarily under enhanced verification?
Should the operating horizon be deliberately limited while an intervention is scheduled?
Should the station stop immediately?
Can production be transferred?
Which material requires containment?
What evidence would justify continued operation?
What conditions must be met before the temporary operating decision is reviewed?
The essential output is therefore not another dashboard.
It is a governed decision: an explicit owner, a documented rationale, required actions, accepted residual risk, review conditions and clear release criteria.
That is where BPM begins to engage with operational reality.
BPM Should Govern Commitments, Not Only Task Sequences
This distinction changes the process-design question.
Instead of asking only:
What activity comes next?
Industrial BPM must also ask:
What must be demonstrated before the organisation can responsibly move forward?
A task-centric process asks whether maintenance completed the inspection.
A decision-centric process also asks what the inspection established, what uncertainty remains, whether the risk profile changed and who authorised the resulting operating condition.
A task-centric process asks whether quality containment was executed.
A decision-centric process also asks whether the containment population remains valid as new evidence becomes available.
A task-centric process records that a restart occurred.
A decision-centric process verifies that defined restart conditions were satisfied before production resumed.
The distinction is important because activity completion does not necessarily mean operational resolution.
A maintenance work order can be closed while the underlying production risk remains unresolved.
A quality deviation can be administratively processed while the physical mechanism is still uncertain.
A downtime event can be closed in MES while the conditions that produced it remain present.
Process maturity therefore cannot be measured only by whether activities were completed according to workflow.
It must also consider whether the organisation reached a controlled operational state.
This is not less process discipline.
It is deeper process discipline.
From Process Integration to Operational Governance
The industrial challenge is therefore larger than connecting MES, CMMS/EAM and QMS.
The objective should be to create a sufficiently coherent operational context that different functions can make decisions from the same underlying reality while retaining their specialised responsibilities.
That requires more than common data.
It requires clarity about ownership, escalation, evidence, decision rights and release authority.
Who owns the abnormal event end to end?
Which function can impose a stop?
Who can authorise temporary operation?
Which evidence is mandatory before restart?
When must engineering become involved?
What constitutes closure?
Does closure mean that every functional workflow has finished, or that the operational condition itself has been demonstrably resolved?
These are BPM questions, but they are not primarily diagramming questions.
They concern the design of the operating model.
The Shopfloor Does Not Need Process Theatre
Factories rarely suffer from a shortage of flowcharts.
They suffer when diagrams, systems and responsibilities become disconnected from the way operational decisions are actually made.
If maintenance, quality and production repeatedly require emergency meetings, calls, spreadsheets and informal escalation to manage the same classes of abnormal events, the first response should not automatically be another workflow.
The organisation should examine what its current process architecture is failing to govern.
Perhaps predictable work requires stronger standardisation.
Perhaps abnormal work requires explicit case ownership.
Perhaps escalation criteria are ambiguous.
Perhaps the same operational event is represented differently across MES, CMMS/EAM and QMS without a shared context.
Perhaps decision rights between production, maintenance and quality have never been made explicit.
Perhaps each function is measured on completing its own process while nobody is accountable for end-to-end operational resolution.
This is where BPM can move beyond process documentation.
Its value is not in forcing every possible industrial situation into a predetermined flowchart.
Its value is in creating enough structure for people to manage uncertainty without sacrificing accountability, traceability, technical evidence or operational control.
The distinction matters.
A mature factory needs disciplined workflows for what can be standardised and disciplined governance for what cannot be predetermined.
When maintenance, quality and production collide, the problem is therefore rarely that the workflow lacks another branch.
The more important question is whether the organisation knows how to make, authorise, document and revisit a sound operational decision when the next step is no longer obvious.
Three Questions to Take Back to the Gemba
- When production, maintenance and quality disagree about the next action, does the operating model define how the decision is made—or only who performs each task?
- Which events currently classified as “process deviations” are actually recurring operational situations that deserve an explicitly governed adaptive response?
- Are MES, CMMS/EAM and quality systems helping the organisation construct a shared operational picture, or are they simply maintaining three technically correct but operationally disconnected versions of the same event?
#OperationalExcellence #BPM #IndustrialMaintenance #MES #AssetManagement #Reliability #ManufacturingExcellence #SmartFactory #ProcessManagement #ContinuousImprovement