Understanding Failure of the Process Kind
- November 3, 2011
- 0 Comments
Jacob Ukelson posted about preventing failure vs. fixing failure. He make a few good points and along the way once again compares ACM / BPM by implication. In a sense, many will argue, ACM is about learning from failure, and BPM about preventing failure:
One of the key reasons companies deploy a BPM suite is to prevent failure. This is a major selling point for many BPM solutions. A key goal of a BPM suite is to enable the deployment of process driven solutions that prevent a deployed process from failing.
But of course, as he points out later, it isn’t always cheaper to prevent failure rather than fix it. ( Not to mention, in some businesses, fixing it is an opportunity to delight the customer. ) This is the crux of it: the arguments about failure are talking past each other. Process Improvement (BPM) should aim to reduce preventable failures of a fairly routine nature. Data entry errors, for example. Logical inconsistencies. This isn’t the primary or only goal, but it certainly is one important form of process improvement for many processes out there. But the idea that we should learn from failure isn’t exactly a new one either… Max Pucher’s blog is an excellent example of this concept in the 70’s and 80’s. The Lean Startup is an excellent example from the startup world.
If you’re familiar with six sigma technique (a fairly mature method that predates my professional career), then you’re likely familiar with the Failure Mode and Effects Analysis (FMEA). In it, you rate possible or anticipated failures by:
- Severity – how bad will it be if it happens?
- Frequency – how likely or how often is it to happen?
- Detectability – how easy and reliable is the detection of the failure (or pre-detection).
Different remedies apply to the failures depending on their characteristics. Often this is applied at a pretty tactical level. But conceptually you can apply it at a macro or management level. Such aphorisms as “worry about what you can control, not what you can’t” and “prepare for the worst hope for the best” are perhaps simplified examples of this kind of thinking. Much business advice could be reduced to focusing on what matters and letting go of what doesn’t. Some failures don’t warrant preventative treatment, and some do. This isn’t exactly a new idea.
The kind of “preventing failure” behaviors that ACM folks are pushing against are mostly organizational or cultural in nature rather than procedural. It isn’t like BPM proponents are advocating that businesses circle the wagons and just focus on preventing failures.
So in summary – where you want to play it safe deploy a process solution focused on managing structured processes, if you need agility (and are willing to accept its associated risk) then you should focus on “first fault problem resolution” for your unstructured processes – rather than try to structure them to prevent failure.
This isn’t as easy as it sounds for some businesses. Let’s talk the First Horizon oil spill disaster in the Gulf of Mexico. Did they need agility or preventing failure out there on the platform? And which situation did their decision-making process most resemble? (Given that individual operators could and would override long-established safety protocol, I think we can infer that they were on the side of more agility vs. more preventative). Other businesses, and other situations, would have a different profile and tolerance for various kinds of failure.
If you’re going to have agility and learn from failure, don’t forget one other thing. You need really good leadership. If you don’t have that, the results of failure might surprise you.