The logic
HAZOP starts from “what was this system designed to do?” and then systematically questions deviations from that intent. The process is divided into nodes; at each node guide words generate deviations:
- no flow / less flow / more flow / reverse flow,
- more pressure / less pressure,
- more temperature / less temperature,
- wrong substance, wrong concentration, contamination,
- maintenance, start-up and shutdown states.
Four columns per deviation
Cause — Consequence — Existing safeguard — Recommendation. An empty fourth column means the third was judged sufficient; that too is a decision, and its reasoning is recorded.
When it is used
- designing a new plant or line, before commissioning,
- when making a significant process change (an input to management of change),
- in periodic reassessment of an existing plant,
- after an incident, to see whether the same deviation is possible elsewhere.
It does not work without a team
HAZOP is not something one person can do at a desk. Operations staff who know the process, engineers who know the design, maintenance and safety sit together, and a facilitator runs the method. A HAZOP table filled in by one person is a document with the right shape and no function.
Where the output goes
Recommendations become an action list with due dates. They also feed bowtie and layer of protection analysis: HAZOP says which scenario is possible, the others say how many layers stand against it.