Measurable Benefit in BPM. Where is it? Part II
- November 18, 2008
- 1 Comments
In this post I am going to pick up where we left off on the topic of measurement (Measurable benefit in BPM. Where is it? Part I). So let’s just dive in. Notwithstanding the reasons for not capturing baseline measurements in a process to begin to understand its current capability, here is the punchline if it isn’t done. When it comes to turning dials and flipping switches with the aspirations of making things better in a business process, without understanding the range of said dials, or the effect of flipping certain switches, you cannot possibly understand what will actually provide the highest yield and what won’t in process improvement. Take Dr. Bruce Banner for instance, he turned a knob too. He didn’t know the real range and things didn’t work out so well (i.e. overdose of gamma radiation and voila! a hulking, destruction toting beast emerged). I have seen this with process improvements many times. A “new” process is put in place and all of a sudden people either (a) don’t see any real difference or, (b) things actually get worse.
What are the basic metrics needed? There are five, with a “really nice to have” sixth metric. With these few metrics you can learn a great deal about a process, and don’t sweat how accurate or precise they are up front. That is something through additional work you figure out but getting even rough numbers up front are enough to get some real progress going. With emphasis- having these with a 95% or better confidence level is not a pre-condition to move on. Here is the definition of the 6:
1) Cycle Time – what is the mean or median total time for an activity, or step in a process to be executed? could be data entry, call handle time, etc.
2) Lead Time – What is the total mean or median time, defined by the process owner or company, that is required to meet the customer demand? The term backlog comes to mind, and the motivation for companies having SLA’s for their vendors (or customers). This is the fundamental measurement of your commitment to deliver to a customer (or the commitment you expect as a customer).
3) Throughput Time – What is the total mean or median time from the absolute beginning to the absolute end of a process. The summation of Cycle Times. Key metric to use for the notion of continuous improvement.
4) “Nice to Have” Takt Time- The time the customer expects a given process output to be delivered to them.
5) Work In Progress (WIP) – This is the volume of transactions or widgets in a process. An invoice, A report, a car, whatever it is your process is built to deliver.
6) Number of Operators – Number of process consumers participating in the process to create and deliver the good or service. Claim Specialists, HR Specialists, etc.
With these few metrics you can start to get a picture of how the process performs. There are other metrics like good versus bad process outputs (such as number of defects, think bad invoices, bad orders, etc) but up front these will really get things moving along. For instance, you will see as you look horizontally what steps quite possibly should be left alone versus the one or two that you need to remediate to promote flow. Processes which execute faster have few defects by and large. So how do I start getting these?
Value Stream Mapping is almost always the defacto starting point to then bridge metrics against processes and their activities. Let’s look at an example, this does not use standard Lean notation. This VSM was made with Lombardi’s Blueprint product. What is important is not the iconography but rather being able to see the big picture and relative detail in one view.
Here you can see the value stream representing the core end-to-end process with a target of completing the process in 72 hours. It shows the highest level (1) and goes to the next level down. This is the equivalent of using sticky notes. I could add meta information behind the scenes describing problems in each of these process areas, but what it doesn’t tell me is where am I going to get the biggest bang in terms of improvement. Now let’s look at the same image with the basic metrics assigned:
Now, with the metrics associated I can get a much better understanding of where to focus. If the target is to deliver the tickets to the customer in 72 hours, but we can see that our Throughput Time is 162 hours, where do we need to focus? Conventional thinking is we should improve each area and that the sum total of improvements will make everything better. However, that is not in fact how it works. We will just waste scarce resources doing that. If we drop the listing process from 2 hrs to 1 hr it is equivalent of a rock in the Grand Canyon. We need to get yield! So look at the Order Fullfillment, if we drop it from CT 120 hrs/LT 40 hrs to something similar to the others, we just created a ton of velocity. With these metrics attached, and with the process decomposition we were able to channel those scarce resources to the weakest link in the chain- Order Fullfillment. As a result, if we carve off 100 cumulative hours and reduce the lead time coming in to this process area we are much closer, if not dead-on, to hitting the takt time of 72 hours.
Could we have improved those other areas? Sure and it’s most likely without these basic metrics we would have tackeled them (possibly at a great expense). Being intellectually incurious about basic data is a key driver behind failing to move the needle in the business; just flat missing the mark because project selection was poorly executed.
Again, its not critical to be dead-on accurate up front, there are techniques to help shore up what measurement variation is really doing to the overall management of the process. The point is understanding that processes have multiple dimensions to it. The picture is just one important part of it. You need the metrics to help focus in on what will make a meaningful difference, and the obvious ROI.
Hope this helps, if you have questions or feedback, please leave a comment or catch me at email@example.com