An out-of-control action plan (OCAP) is a written, pre-agreed reaction plan that tells an operator exactly what to do the moment a control chart signals: contain what is running, work a fixed diagnostic sequence, correct the cause, and verify that control returns, before the process makes more bad parts.
A control chart is only half a system. It tells you the process went unstable; it says nothing about what to do next. Without a plan, that gap fills with improvisation: the operator tweaks a knob, calls a supervisor, or keeps running and hopes. An OCAP closes the gap. It is the reaction plan attached to the chart, and it is the difference between a signal that stops scrap and a signal that just gets initialed. This guide covers what triggers an OCAP, what belongs in one, how to write it step by step, and how it differs from a control plan and a CAPA.
What is an out-of-control action plan?
An OCAP is a pre-written procedure that pairs each control-chart signal with a fixed response. Think of it as the flowchart taped next to the chart: if the chart does this, you do that, in this order, and here is who to call if it does not come back. It exists so the response does not depend on who is standing at the machine. A veteran and a new hire both follow the same path, which is the whole point of statistical process control: consistent reaction, not heroics.
The plan lives at the point of work, not in a binder. Its job is to compress the time between the signal and the fix, because every minute the process runs unstable it may be making parts that will later be sorted, reworked, or scrapped. A well-built OCAP takes the response from hours, waiting for a meeting, to minutes, follow the card, which is exactly why plants running control charts without a reaction plan rarely capture the savings the charts promised.
When does an OCAP trigger?
An OCAP triggers on a control-chart signal, not on a bad part. That distinction is the whole reason it saves money. A part failing its specification is a defect you already made. A control-chart signal is the process telling you it has drifted from its stable behavior, often while the parts are still inside spec, which is your chance to correct before the defects arrive. This is the practical payoff of understanding control limits versus specification limits: control limits describe the process, specification limits describe the customer, and the OCAP reacts to the process first.
The signals that fire an OCAP are the standard out-of-control rules: a single point beyond a control limit, and the nonrandom patterns, a run on one side of the center line, a steady trend, points hugging a limit, that say the process shifted even though no single point broke out. The OCAP does not need to react identically to all of them. A point beyond a limit may demand an immediate stop; a slow trend may call for a check at the next scheduled interval. What matters is that each signal maps to a defined response, so no signal is left to interpretation.
What goes into an out-of-control action plan?
Every OCAP answers the same handful of questions in a fixed order, so an operator can work it under pressure without deciding anything they should not have to decide. Leave any one of these out and the plan stalls at exactly the moment it needs to move.
| OCAP element | The question it answers |
|---|---|
| Trigger | Which chart signal are we reacting to? Point out of limits, trend, run? |
| Containment | What do we do with product right now? Stop, quarantine, hold the last skid? |
| Diagnostic sequence | What do we check, in what order, from most likely cause to least? |
| Correction | What adjustment or repair fixes the cause we found? |
| Verification | How do we confirm the process is back in control before releasing? |
| Escalation | Who do we call, and after how long, if the operator cannot restore control? |
| Record | Where is the signal, the cause, and the action logged for later analysis? |
The diagnostic sequence is where a good OCAP earns its keep. It orders the likely causes so the operator checks the fastest, most probable one first, tool wear, a loose fixture, a material lot change, instead of chasing the process at random. That order should come from history: what has actually caused this signal on this process before, drawn from your defect tracking record rather than from guesswork.
How do you write an OCAP step by step?
You build an OCAP one chart at a time, with the people who run the process, and you keep it short enough to work at the machine. The sequence below turns a blank template into a card an operator can actually follow.
- Pick the chart and the characteristic. One OCAP covers one control chart on one characteristic. Do not write a generic plan for the whole line; the diagnostics differ by feature.
- List the signals you will react to. Decide which out-of-control rules apply, a point beyond a limit, a run, a trend, and whether each demands an immediate stop or a scheduled check.
- Define containment for each signal. State plainly what happens to product the moment the signal fires: keep running, hold the last hour, quarantine since the last good check, or stop the machine.
- Order the diagnostic checks. With the operators and process engineer, rank the likely causes by how often they actually cause this signal and how fast they are to check, then write them in that order.
- Attach the correction to each cause. For every diagnostic branch, state the fix and who is authorized to make it, so the operator is not waiting for permission to do the obvious.
- Set the verification. Define how the operator confirms control returned, usually a fresh subgroup that lands back inside the limits, before product is released again.
- Set escalation with a clock. Name who gets called and after how long if control does not return, so a stuck process does not sit unstable while the operator keeps trying.
- Route the record. Decide where the signal, cause, and action are logged. If the same signal keeps recurring, that record is what turns an OCAP reaction into a permanent corrective action.
How is an OCAP different from a control plan and a CAPA?
These three get confused because they all sound like quality paperwork, but they run at different speeds and answer different questions. The OCAP is the fast one: it fires in real time when a chart signals and restores control in minutes. A control plan is the standing document that says what to measure, how often, and with what method; the OCAP is usually the reaction column inside or attached to it. A CAPA is the slow, permanent one: when the same signal keeps firing, the CAPA process hunts the root cause and changes the process so the signal stops recurring.
| Question | OCAP | Control plan | CAPA |
|---|---|---|---|
| Trigger | A live control-chart signal | Written before production starts | A recurring problem or audit finding |
| Speed | Minutes, at the machine | Standing reference | Days to weeks, off-line |
| Goal | Restore control now | Define what and how to monitor | Remove the root cause permanently |
| Owner | The operator on shift | Quality and process engineering | A cross-functional team |
By the numbers: why the reaction plan matters
Control charts are a mature, standardized method precisely because the reaction to a signal is supposed to be defined, not improvised. ASQ describes the control chart as a graph used to study how a process changes over time, with control limits that distinguish a stable process from one that needs attention (ASQ, What is a Control Chart?). The NIST/SEMATECH Engineering Statistics Handbook frames the entire point of process monitoring as signaling when corrective action is necessary, which is the job an OCAP performs (NIST/SEMATECH, Process Monitoring and Control). A chart without a defined reaction is a smoke detector with no one assigned to grab the extinguisher: the alarm sounds, and the fire still spreads.
What are the most common OCAP mistakes?
The biggest is not having one, running control charts, initialing the out-of-limit points, and never changing anything. A close second is writing an OCAP so vague it reads investigate and adjust as needed, which is not a plan, it is a shrug in a box. The diagnostic sequence has to name real causes in a real order, or the operator is back to guessing.
The other frequent errors: no containment step, so bad product keeps flowing while the operator troubleshoots; no verification, so the process is released before anyone confirms it is actually back in control; no escalation clock, so a stuck operator keeps trying alone for an hour; and, most quietly damaging, no record, so the same signal fires next week and no one connects the two. An OCAP that is never logged can never graduate into a CAPA, which means the root cause lives forever.
How do you keep an OCAP working on the floor?
An OCAP works when the signal, the reaction, and the record all live at the point of work. The failure mode is not usually a bad plan; it is a plan that is disconnected from the chart. When the chart is on a clipboard and the OCAP is in a binder, the operator has to notice the signal, find the plan, and log the response by hand, and under production pressure one of those three gets skipped.
Closing that loop is where live capture changes the outcome. When the control chart and its OCAP sit at the station together, the signal is impossible to miss, the reaction steps are one tap away, and the cause and action are logged the moment the operator works them, not reconstructed from memory at shift end. That is the capability Harmony brings to the point of work through station-level data capture so a signal turns into a documented, consistent reaction every time and the record builds the history a future CAPA needs. CLS made exactly that shift, from a chart that got initialed to a signal that got worked while the run was still going, and paired the fast reaction of an OCAP with the discipline of a p-chart or any other chart they run. No rip-and-replace.