PROCESS RISK – How vulnerable are your processes?

Do you ever experience…

• Repeating reasons for poor quality, especially escaping to your paying customers?
• High dependencies on manual inspection?
• Processes operating on more than one ‘standardised’ best practice way?
• Harm to critical equipment and/or personnel?

Then it’s quite possible that your methods of evaluating process risk may not be doing their job effectively.

As much as we expect our processes to operate correctly, if they fail then we should be looking at the reasons why the ‘systems’ we deploy don’t absolutely prevent failure (as opposed to relying on detecting when it’s already happened). People have an inherent ability to find the weaknesses in all processes. That’s how we’re genetically designed – to learn from trial and error. Accept that making mistakes is a natural phenomenon.

The saying ‘some of the people can be right all of the time, all of the people can be right some of the time but all of the people can’t be right all of the time’ isn’t completely correct. Nobody can be right all of the time. Therefore, we need to be sure that our systems are designed to deliver right-first-time processing and functionality based on effective error-proof principles which alleviate the risks associated with manual influences.

The most effective technique available for evaluating the risks of processes and products is the Failure Modes and Effects Analysis (FMEA). Fundamentally this technique breaks risk analysis into three parts –

• what might go wrong
• what is the probability of going wrong, and
• what are the consequences of going wrong

Most people have perhaps heard about this technique, some may have actually had experience deploying it. The sad fact is, though, that the technique is either not used, or when it is deployed, it’s not deployed effectively.

Here are some examples from my own experience of FMEA deployment issues, all with a common outcome – ineffective and costly results.

Not maintained

Many organisations practise some form of continuous improvement or business process re-engineering, essential because processes and products do not stay the same forever. As new technologies become available it makes perfect sense to exploit how these can improve existing products and processes. To stand still in business is no longer an option.

Unfortunately, dynamic changes in products and processes require effective closed-loop change management systems. If effective change systems are not in place, or ineffective, chaos will ensue, resulting in more than one ‘version of the truth’ being allowed to exist in your processes. There can only ever be ‘one best way’ recognised in what we do. (By ‘effective’ change management systems I mean that they must be able to respond quickly as well as correctly).

Sometime change systems just break down because of ineffective or unclear lines of communication or ownership….

Confused ownership

All process or product changes must be reviewed effectively by all relevant parties, from initial design intent through to the delivery to the end user. The longer and more complex this chain is, the slower the change approval process can take, and the higher is the risk that people in the decision chain may be overlooked (purposefully or otherwise) in order to expedite timely change. So careful attention to clear lines of communication and ownership must be created, maintained and managed.

Some organisations believe that, because an FMEA system will reside in the Quality Management System (QMS), then the ‘owners’ of the FMEA system must therefore be the Quality department – not necessarily correct. Design FMEA’s need to be ‘owned’ by the Design department, with clear lines of communication into product and process engineering and back into the Quality department. Process PMEA’s need to be ‘owned’ by the Process Engineering department, with clear lines of communication into design engineering as well as Quality.

Quite often, non-operational processes tend to be overlooked on FMEA’s. The perception being that unless we are physically ‘making’ something then an FMEA doesn’t apply. Wrong!

Not an appropriate technique for non-manufacturing processes

What differentiates a manufacturing process from a non-manufacturing process? In truth – nothing, they both have one thing in common – A PROCESS. Administrative processes may now have migrated into IT based systems. Because they have effectively moved from ‘paper’ into electronic transactions, administrative processes have disappeared into the ‘ether’. But they are still processes, with all the same inherent risks as manufacturing processes.

Generally, administrative processes are often much more complex structures than manufacturing processes. More things to go wrong! It’s a false economy to assume that electronic systems are automatically error-proofed, they’re just as vulnerable to the influence of people. Despite all the ‘hype’ about Artificial Intelligence and what this will do for society, we still have to rely on ‘people’ ultimately making good decisions. All that IT has achieved therefore is hide complex (and by definition, riskier) decision making behind a screen. You know the saying ‘rubbish in, rubbish out’. IT systems can be very efficient and reliable at processing rubbish.

Incorrectly constructed

How do you produce a consistent, effective approach to FMEA’s that effectively risk assesses all processes in a comparable manner? Not easy. Learning how to do FMEA risk assessments just from a manual won’t deliver enough practical understanding to be effective.

The FMEA learning curve is like learning to ride a bike. You have to accept you’ll fall over a few times to start with, but once you get your balance you won’t forget the right way to stay up. Reading a manual on FMEA alone is almost certain to result in non-standard and inconsistent approaches to deploying them. You need experienced mentors to coach and embed best practise. The ideal learning process takes place when FMEA’s are developed in-situ with a focussed team of local participants where a whole process stream can be completed effectively and correctly within relatively short time frames using a ‘rapid deployment’ model. This leaves the local teams quite capable of continuing to extend their risk assessment programmes across other processes with minimal oversight needed.

There needs to be a balance between information overkill and insufficient information capture however for the FMEA’s to be effective at assessing critical risk….

Too much/not enough detail

When to stop digging into detail when constructing an FMEA can be subjective. A purist will say it’s important to be absolutely thorough, and why not if you have unlimited time and resources. In the real world though it’s necessary to use effective root cause analysis to drive down to the sources of potential as well as actual failure so an FMEA is able to risk assess in sufficient depth, but not dwell too much on the fact you will never be able to predict absolutely every scenario. There are ways to conduct effective root cause analysis that don’t necessarily ‘break the bank’ in terms of time required to deploy and their correct application saves time and effort  (For further reading see links 1 & 2 below). What’s a bigger concern is insufficient analysis of root causes.

Generic v’s product specific

Some people suggest there is no place for ‘generic’ FMEA’s that only document process risks common to all products and processes. The alternative is to have FMEA’s for absolutely every permutation of products and processes which is effectively impractical to achieve and, generally, quite unnecessary. Product specific risks can easily be integrated into ‘generic’ FMEA’s.

Clearly in a formal FMEA system managed within a QMS, then all FMEA’s must be comprehensively cross-referenced plans to control product specific processes though….

FMEA’s Don’t align with control plans

Control plans are the documentary evidence that maintain and manage quality and performance. There is no point in having good FMEA’s that don’t do something to protect the business. The Control Plan is the ‘extension’ of the intent of the FMEA that delivers this protection. Missing, incomplete or just incorrect control plans will result in failure. Control plans are your statement of intent that proves you are in control of your processes.

Control plans are typically owned by the Quality Department but must also be carefully cross-referenced to their corresponding FMEA’s. Be sure you have a process control mechanism in place to augment your FMEA risk assessment systems.

They cost too much to implement

FMEA systems, should form an integral and formalised part of a business’ QMS. Developing effective FMEA based risk assessment of your processes will take time and resource – a lot of it! There is also an ongoing cost burden of maintaining them. However, the benefits FMEA/Control plans deliver far outweigh the risks of not having them at all.

Some organisation do take a ‘cheap’ option to deploying FMEA systems. They use the techniques specifically within individual change projects, and more-so specifically within sub-sections of a specific overall process. This results in a ‘patchwork quilt’ of FMEA ‘snippets’ often leading to many of the issues discussed above and ultimately a completely unmanageable risk assessment strategy.

To summarise then, be brave enough to invest correctly in a good risk management strategy that will protect your organisation from harm well into your future. Speak to us to reassure you about how to avoid the above pitfalls – talk costs nothing, but avoiding the issues can be a killer.
References:
1. How do you get Root Cause Analysis to work effectively? – Part 2: 5-why analysis http://www.palomaconsulting.com/blog/2015/08/28/how-do-you-get-root-cause-analysis-to-work-effectively-part-2-5-why-analysis/
2. How do you get Root Cause Analysis to work effectively? – Part 3: C & E Analysis http://www.palomaconsulting.com/blog/2015/09/21/how-do-you-get-root-cause-analysis-to-work-effectively-part-3-c-e-analysis/

 

Leave a Reply

Your email address will not be published. Required fields are marked *