A Glass Half-Empty?
- May 27, 2009
- 1 Comments
A wonderful example of looking at the same glass and seeing it as half-empty rather than half-full, here’s the headline from an article I just read: “Just 15% of Companies that Implemented a BPM System are Realizing End-User Productivity Gains of More than 50%”
(or should I say, 15% full or 85% empty? )
Its a good read of an article, but let me write the headline differently using the same statistics:
“15% of Companies implementing a BPM System realize end-user productivity gains of more than 50%”
That sounds, actually, pretty good. Presumably some larger percentage of these companies implementing BPM Systems achieve some smaller end-user productivity gains. It also seems that these statistics are being reported in a vacuum. Are end-user productivity gains the *only* goal of such implementations? What about better customer service? Lower defect rates? Higher throughput without a loss of quality? Faster turnaround time? etc.
Reading into the (slightly) more detailed stats at the bottom of the article, only 1.4% of BPM Projects had negative end-user productivity impact, and 46% fell into the “don’t know” category. That’s the real problem: too many of the companies implementing BPM Systems really had no effective way to measure worker productivity *prior* to implementing BPM. So often the better apples-to-apples comparisons are other statistics that are affected by end-user productivity but are secondary indicators:
- Throughput of your process (# of instances of the process in a given timeframe)
- Average and Median completion time of a process instance
- Number of defects (customer complaints, inaccurate orders, etc) per million (for example)
- Customer Service scores
Another question asks how often end-users are involved in designing their own workarounds to get around the system. 46.5% said often, and 38.4% said occasionally. This is a great argument for why a BPM initiative needs to be a program, and not just a one-and-done project. Those workarounds that end users are designing need to be sussed out, examined, discussed, and incorporated into future BPM iterations… In other words, we want continuous process improvement.
I’m looking at the same statistics and seeing the glass half-full…