How to distinguish hype from real value

Early January 2012 I visited an exhibition about the mythical Unicorn in a beautiful medieval castle in ‘s Heerenberg in the Netherlands. It struck me how people believed in the existence of the Unicorn for ages, without it ever being truly seen, and how they believed that the powder of the Unicorn horn was a cure for every disease, even from poisoning. I would definitely recommend you visiting this exhibition before March 1, 2012 if you have the opportunity, but otherwise also Wikipedia provides great background.

Now I am not going to declare that companies implementing BPM are like those hunting the Unicorn. I think BPM is real and offers real value.

However, I do believe that the benefits of BPM are still overhyped in too many occasions. Yes, there are true benefits resulting from monitoring and managing your business processes, like:

1. Faster process response times and reduced error rates by automating those parts of the process that can be completed without user input.
2. Allowing users to spend more time on things that really matter (customers, important decisions)
3. Knowing process workload and where processes run the risk of not meeting Service Level Agreements.

In other words, BPM allows you (or: should allow you) to be in control.

On the other hand there are things to be aware of when you embark on a BPM quest. These are just a few examples of hypes that I think you should be aware off:

1. The magical flowchart – You will hear vendors say: “Just model (draw) your business processes in our BPM tool, push a button, and you will have a running process”. This is an absolute lie. The work required to make a business process executable and manageable should never be reduced to just drawing a high-level (BPMN) model. In fact, anyone who tried implementing a business process to a BPM Tool knows how hard it is to transform the logical, high level buisiness process to a executable process that deals with the required detail, variations of the process, business exceptions and error handling.
2. Implementing BPM will bring you agility – Again, the believe here is that the fact that the process in modeled as a flowchart and not “coded” will allow you to quickly make changes as the business requirements change. My view on this is: You will have to be extremely disciplined and limit the level of detail that you implement in your process model to actually achieve better agility with BPM. Using a BPM tool without caution and without the right methodology will just cast your business processes in concrete, and your nightmares will be worse compared to the time before you introduced the BPM tool.
3. Your Business users will be able to change your process models, so you no longer are dependent on IT resources to put them to action – This is probably the “holy grail” of BPM. And however nice it sounds to not depend on IT resources, this is not realistic. You will need boundary spanners, people that bridge the gap between the business and its language, and the technobable of the BPM implementation team to actually get the thing working. There certainly are solutions that may help the business users modify some aspects of their processes through a user interface. But do not expect the vendor tools to be the solution! You will need to go through a requirements analysis and solutions design, just like you do in non-BPM projects!
4. Implement your processes in our BPM tool and you will instantly be able to monitor and manage your processes and workforce better – Most BPM Tools provide some crude dashboard that allow you to see processes, hopefully provides some graphs showing user load, and maybe even some statistical information. The reality of you business requirements in terms of manageability and monitoring (Service Level Agreements (SLAs); Key Performance Indicators (KPIs)) will most likely not fit 100% in the simple standard model that the BPM tool provides. First best practice here is to start gathering requirements in terms of manageability and monitoring as soon as you have decided a process will be moved to a BPM tool. Secondly, reserve time in the project scope to deal with the design of the right dashboards etc. to allow you to actually monitor and manage your business process once it runs!

My plan is to continue to blog here and crack some of the difficult issues that your vendor doesn’t want to talk about in the sales cycle.

I look forward to your responses!

Follow