Beginner's Guide to Performance Reports
- April 25, 2011
- 0 Comments
John Reynolds gives a beginner’s guide to Process Performance Reports on his blog. Using Websphere Lombardi Edition, he shows a few diagrams and gives good advice regarding how to build up the tracked data for your process reports.
Of course, if you’re not using Lombardi Edition (or various versions of Teamworks and IBM BPM), you might not be able to relate to these diagrams- they include the tracking point metaphor that Lombardi introduced way back in 2004 to allow for a transparent snapshot of process instance data. It really makes it trivial to capture snapshots and timing data for use in correlations in reports.
John does say one or two things I’d modify, such as:
Process Performance is all about “How long did it take?”. If you want to know “How long?” then you have to know when “it” started and when “it” finished.
I’d say, rather, that this is one of the most common kinds of reports – and in IBM BPM, one of the easiest to produce. There are other quite interesting reports that are similarly trivial to capture:
- How many of X did each person on the team process by month (or by week or by day, etc.)
- How many exceptions (complaints/defects/etc.) did we process by customer or by region (comparing performance)
- How much rework is happening?
- What percentage is going down the happy path versus exceptions?
- What is the typical # of exceptions per item?
- How many exceptions get “fixed the first time” (ie, once known, the issue is fixed correctly).
With some demographic data on each snapshot, we can really do interesting correlations (using the optimizer or your own custom reporting techniques). One of the uses of this data is to fine-tune the process. A favorite demonstration of this capability was to look at the correlation between the size of a dispute in a dispute resolution process. If 90+% of disputes under a certain $ amount (possibly in combination with other criteria) are being approved, perhaps it makes sense to insert an auto-approve decision rule in front of the manual activity that requires a person to look at the request and approve or deny.