I’m in the middle of writing a procedure for conducting FMEA. My question is: what range of values for severity, occurence and detection should I define?
Should the procedure strictly define the range (e.g. 1-10 for each of the parameters) or the R.A.Team defines this range during risk assesment process?
And I’d also like to know how precisely should the range be described? I mean: shall I describe each an every value (1,2,3,…10) or just e.g. ‘1,4,7,10’?
By the way: isn’t the 1-10 range too wide?
to begin with: In my opinion the range 1 - 10 is too “detailed”. Last year, at a validation workshop in San Diego the consense was that three levels are enough, and five can be used within experienced risk assessment teams with a very good knowledge of the process and its risks. After all, what is intended is a “quantification” of a qualitative appraisal.
With this in mind, you can leave the levels open to a number the RA team is comfortable with, and with a maximum of five levels you can describe each value quite easily.
Hello Valtschaq, I´m in similar conditions.
In my particular case, I still don´t understand very well how to evaluate the Severity, Ocurrence and Detection like you. My idea is, first assess the RPN for all the functionalities that will be defined in FS and then will be tested in OQ.
I need to undestand very well the FMEA, and its procedure for to build my SOP.
All the information that you send me, will be of great help to me.
I settled on a three-level system for a risk-based analysis. It also lends well to a graphical Boston Grid that is nice in presentations. A picture is worth a thousand words!
For our new risk programme (I supply automation systems to pharma end users), we expect the end user to perform an overall preliminary risk analysis. For say a green field site, we might be supplying the automation for the process and HVAC but the secondary packaging and USP or WFI would be from someone else so we don’t want our involvement up front to be too detailed.
Once the project enters the design phase then we do a “Functional Risk Assessment” (really just a slightly more rigorous Criticality Assessment in many ways) in parallel with the Functional Specification. We do NOT embed the FRA into the FS because they really need to be updated asynchronously and getting them signed off etc. is a royal pain. Also I have seen on many projects that as funds diminish that one or more life cycle documents starts to get neglected, so keeping them separate allows a culling process when you need to pick and chose which document to neglect (I don’t want to neglect any as the supplier, but if the customer doesn’t want to pay you because the stainless cost twice as much as they budgeted - then you’re stuck!).
Our FRA is based on Excel and the FS is based on Word - another reason to keep them separate. The Excel macros allow for 1-3, 1-5, 1-10 etc. levels so the system is flexible. There is a statistical method associated with FMEA and FMCEA for certain kinds of risk assessment in the 1-10 category but this is really aimed at someone who is making 10,000 widgets for automotive use and wants to categorise failure rates. Certainly useless for pharmaceutical.
The world of automation - last on the scene when the money has run out!
