A follow-up on yesterday’s post
One of the gaps that I find in BPM projects is the reporting.
For one of the most important business pains, it doesn’t get the attention it deserves.
Hours, days, months are spent on designing the process. Reporting – it’s an afterthought…
Reporting is not part of the process design (…I don’t think it’s defined in the BPMN either..)
If I’m lucky – it’s defined in the last paragraph of the technical spec or the functionality spec – and it’s probably defined badly.
So I have to put on my creative cap…
Yes, there are always the out-of-the-box process reports, but that’s not the customer is looking for.
In BPM suites, most of the out-of-the-box process reporting is done on the process metadata and most of the analysis is done on the process performance.
There is little on the business data inside the process, and that’s actually what the customer needs!
Below, I’ve written the steps that I take to build the reporting platform. It’s far from perfect, nothing to write home about, but it gets the job done.
1. Find the business pain.
2. Create gauges for the high management
3. Create crunch number reports for middle management
4. Create a mechanism for managers to create their own reports
Finding the Business Pain.
Sometimes finding the business pain is simple, the customer knows what they want. Sometimes it’s a bit more trickier, internal politics that they don’t want to expose. It usually takes a coffee (or a beer) to get to the bottom of it.
Most of the business pains that I’ve seen run something along the following lines:
• We want to find the slackers
• We want to be able to prove to the customer that we are on time
• We want to be able to prove to the customer that they are in the wrong
• We want to prove to the bosses that the company can’t do without us.
Managers love pretty gauges. Sales love showing them. Visualization.
They are not as accurate as real crunch number reporting, but they do give a good indicator on what’s happening.
I‘ve even had a manager tell me that he wakes up in the morning, turns on his laptop, opens the portal. If the gauge is showing green – he turns around and sleeps for another hour. If it’s red – he gets out of bed and goes to work..
The gauges need to show answers to the business pains.
• Show me the efficiency-rate per employee in my department
• Show me the SLAs and KPIs for the last 3 months per customer.
• Show me the number of rejected/wasted time/redundant proposals sent to the customer.
• Show me the revenue/deals won/successful requests of my department
Crunch Number Reports
These are the real reports middle-management want. Numbers, drilldowns…
If possible, to be sent directly to them every Monday morning at 7:00. “Exporting to Excel and PDF would be nice”. “Can I have a logo on the top left corner?”
“I want to see all the information relevant to my department, except for closed, declined and anything marked with ‘QR101’ prefix.”
Create a mechanism for managers to create their own reports
Creating reports is the fun part of my projects. It a challenge between me and the database. It’s stimulating (in a geeky kind of way..)
But creating proper reports take time. Managers want the ability to create their own reports by themselves, now.
I use Microsoft’s Reporting Services to create models that enable them to build their own reports using the report wizard. I’m usually bashing Microsoft, but this time they did come up with a nifty piece of software that solves the business pain, and is quite user friendly and easy to use. I usually create around 5 models, leave them with the business analyst and come back a month later to find that they have created 50 reports by themselves. Kudos to Microsoft here.
That said, I’m sure non-Microsoft vendors have the same tools and functionality.
As I said before, it gets the job done. The customer is more than happy and I’ve ticked all the boxes.
But I get this feeling that with all the BPM notations, BPM methodologies and – we are still missing out on a better way to do reporting in BPM.