|
A Process Hazards Analysis (PHA) may very well be the best tool that has come along to the safety profession since the fire extinguisher! I am kidding of course, well sort of, as the PHA methodologies (and there are many) can be used in so many situations that it is used outside of PSM/RMP as often as it is within the standard requirements of the government regulations. PHA's were not developed for OSHA's PSM standard; they were around long before that standard was even a thought within the ranks of OSHA. But as with any tool, it can be, and unfortunately often times it is, misused in its application and method. This is what I mean...
We do PHA's in order to methodilically evaluate a hazardous process, most often times it is a chemical process. And for those of us familar with OSHA's PSM standard we know that one of the requirements that OSHA places on a PHA Team is that they MUST consider the Consequences of failure of engineering and administrative controls. And this is where I take issue with many of the PHAs I have examined/audited or facilitated over the past 20 years. There is of course multiple ways to go about meeting the PHA requirements found in PSM/RMP standards, but the following is the method that I have found works best to keep everyone focused on the deviation, cause(s), and consequence(s) currently being analyzed. I will use the HAZOP methodology in my example, but keep in mind these same principles could/should be applied to whatever methodology the team is utilizing.
In doing the PHA, the team will establish the CRITICAL process parameters that are applicable for the node being analyzed. Critical parameters are those process parameters that if outside its acceptable limit(s) it will result in a process upset or release of the HHC. Critical Parameters are items like flow, level, temperature, pressure, pH, viscosity, etc. One thing I like to do is use the PSI data to determine what the engineers determined are the "safe upper and lower limits". It is ABSOLUTELY a necessity that the PSI be COMPLETED as the team needs the safe upper and lower limits QUANTIFIED so that it is clear to them what TOO MUCH LEVEL actually is!
Next the team will establish the DEVIATIONS that can occur with EACH PARAMETER, such as NO, TOO MUCH, NOT ENOUGH, etc. The team will basically take each critical parameter and ask what happens when the parameter is exceeded (exceeding safe upper limit) or not achieved (exceeding safe lower limit).
Now we are ready to begin the study and this is where things actually get interesting! Remember, we must consider the Consequences of failure of engineering and administrative controls in each scenario. If you have ever participated in a PHA and the facilitator ask, "NO FLOW - what can CAUSE no flow", how many times have we seen the group state "there is no EHS consequence, only loss of production". As a facilitator, we can can NOT let the team skip to consequences when the step is to identify CAUSES of NO FLOW. We will get to CONSEQUENCES in the next step. Force the team to think "outside the box" in their attempt to identify situations where we do not achieve 100% FLOW from point A to point B as shown on the P&ID being used. Most teams would automatically picture a pipe full of product and just sitting there; but there are NO FLOW scenarios that have a much larger impact! Take the cause of "Line/Pipe Failure" which results in Loss of Primary Containment (LOPC) and a release to the ground/air. Most teams would not get into the multiple causes of this LOPC, but we MUST consider the CONSEQUENCES of this spill/release between points A and B. So if we let the team just "assume" there is no consequence to NO FLOW then we very well may be missing some critical failures. Another NO FLOW item that needs to be discussed is "Drain/Vent Valve OPEN". This is a good example of why P&ID's need to be detailed! Different size drain/vent valves and/or their location can have different consequences and may need to be analyzed separately. By this I mean a drain/vent valve inside a dike will have "secondary containment" as a safeguard, but a "drain/vent valve" outside the dike would NOT have secondary containment and may even be in an area that is not designed to see the material released!!!
But I digress! The real meaning of this article is to try and establish how a PHA team should go about analyzing the consequences of failure of engineering and administrative controls. As I stated above, teams are quick to point out that a scenario will result in no EHS consequence because they are thinking "outside the bubble" of their process as they understand it. As a facilitator we need to ask why/how there would be no consequence. The answer we get may surprise you..."the incident will never happen because we have "this", "this", and "this" in place to make sure it does not happen". Well it is those "this", "this", and "this" that we have to consider failing and what would the consequence be then! By not letting the team assume the event will never happen, we can keep them focused on the consequences and this will actually make the safeguards stand out even more and stress their significance! Facility personnel will become complacent in their reliance on their safeguards - it happens to everyone; but in a PHA, complacency will result in not analyzing the consequences of failure of engineering and administrative controls. WE need to EVALUATE the CAUSE(S) and CONSEQUENCE(S) WITHOUT any safeguards in place!
As a PHA team we review ALL deviations by identifying causes, then evaluating the consequences of these deviations, and then (and ONLY then) do we begin to identify the safe guards that will reduce the likelihood of the consequence(s) occurring. But we have to consider the consequences will occur because all of the safeguards fail, much like a line of domino's falling. If we follow this order, we will not only be analyzing the consequences of failure of engineering and administrative controls we will be painting a picture for the PHA team to recognize the significance of their safeguards as well as meeting the letter of the standard.
As for analyzing the consequences of failure of administrative controls, I do not let those be listed as safeguards in my PHA's. Much like "training" is rarely listed in my PHA's. Too often I have done revalidations for a client and then been invited back to conduct their three year audit only to discover there is no real SOP for some of the scenarios and the documents the facility calls SOPs are far from being compliant! I also find gaps in training, in that either certain operators fell through the cracks when it came to training on a particular SOP or worse yet, the facility does not actually train on their SOPs! Think about it, if we are going to claim an SOP and Training will PREVENT a valving error that leads to the consequence, wouldn't we expect the valving arrangement to be very detailed in the SOP and that the valves be properly tagged in the field, on the P&ID and listed in the SOP? Well if we do not have this level of detail in the SOP and the workers are not being trained on this SOP, then there is no way we should be laying claim to this SOP as a safeguard to PREVENT the error from being made. Maybe some facilities are VERY MATRURE in their process safety culture and have achieved this level of detail in their administrative controls, but the vast majority of facilities are still working towards this level of process safety and until it is achieved, administrative controls should be used SPARINGLY as a safeguard to the PHA scenarios.
We need to identify the causes of the deviation, the consequence(s) of each cause, and then establish the engineering controls safeguards that are in place that will either PREVENT the incident from initiating, PROTECT assets when the incident occurs, and MITIGATE the consequences of the incident. By doing the PHA in this order we will be assured that each scenario analyzed the consequences of failure of engineering and administrative controls. Letting a PHA team assume a scenario will not initiate because of the safeguards in place is NOT how a PHA was meant to be done!
|