Preventing Failure vs Fixing Failure

There has been a lot of discussion on the value of failure in the ACM\BPM community in last few weeks (Failure is Essential to Knowledge WorkThe Value of Failure, Preventable Faillure, Unavoidable Failure, Intelligent Failure).  Of course failure is part of any process (i.e. for some reason the process didn’t achieve a desired result) , though sometimes we use the word exception in the context of a process.

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. As everyone knows – preventing failure is a lot cheaper than fixing it, so any technology that can help prevent failure is valuable. But is that really true in every context?

When deploying a BPM solution the question you need to ask is whether your processes are well defined enough and correct enough that you can really focus on preventing failure (and don’t forget in most cases  preventing failure is equivalent to limiting options). If that isn’t true (which is the case more often then people think) – then you should focus on the ability to fix failure fast, and correctly. Or said another way – the focus needs to be on “first fault failure resolution” capability rather than failure prevention capability.

I found this document from Netflix which I think is very interesting given the public failures they have gone through lately.  It has a lot of insight from a rapidly growing company about how they think about process (starting on slide 44), though the derogatory term bureaucracy is used. Here are some interesting process related quotes from the presentation:

  • Process brings seductively strong  near term outcome
  • “Good” process helps talented people get more done
  • “Bad” process tries to prevent recoverable mistakes
  • Embrace Context – Not Control
  • In a creative-inventive market, not a safety-critical market like medicine or nuclear power. You may have heard preventing error is cheaper than fixing it — Yes, in manufacturing or medicine…but not so in creative environments.

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.

4 Responses to “Preventing Failure vs Fixing Failure”

  1. kswenson Says:

    Good post. Some nice links.

    Possibly relevant is this one about Netflix as well: http://social-biz.org/2011/10/11/netflix-agility/

  2. Understanding Failure of the Process Kind » Process for the Enterprise Says:

    […] 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. […]

  3. dave cohen Says:

    Jacob,
    How could i learn more about action base and related technologies. We are looking for tools at Procter & Gamble (where i work) to improve decision tracking. I tried to contact someone at the action base web site but got no response and i found your blog and that they were acquired. Thanks in advance for your guidance

  4. iqu, llc Says:

    Nice post Jacob,

    Failure of a process is inevitable, (what does failure mean, how do we define failure – topic for another post) any attempt to “prevent” failure is a misconception. Failure is risk and risk can only be managed. Many processes fail in workflow morphing from structured to unstructured. Using a Persona methodology for figuring out what the user requires of the application, who it is, what do they do, what are the paint points, etc. Looking at individual work. Keep foremost in mind that each knowledge worker works differently. Identifying structured and unstructured work within a process along with taking a user first view of work are two approaches towards managing failure; not to forget about control, i.e. governance.

    I invite you to read and subscribe to iblog @ iqullc.com. Looking forward to more post, see you on Linkedin.

    -Stephanie

Leave a reply to dave cohen Cancel reply