Why (I think) Reporting Matters

I've been trying to figure out why I've spent so much of my dev life working with reports.

After all, some developers I respect very much will say things like "I don't do reports".  Usually they mean they are not interested in SQL Server Reporting Services, or VFP FRXs, or Crystal Reports, or some other tool.  But sometimes they truly mean they don't care much about application output, period.

After all, the work of designing, gathering, validating, and nurturing data is the real dev work, right?  Any user can connect to a database and generate a pretty presentation from the data in Excel.

So… why do I care so much about output?

Application output = the business result today.

To many business users, even really smart ones, the reports are the application.

As part of the data makeover caused by enterprise application lurch that I mentioned the other day, I've been looking into a loss of granular information at the order line level that seems likely to occur.

"When entering order lines in Enterprise App Brand X, you've had the opportunity to associate one line to another," I pointed out, to a user who conducts the a weekly c-level meeting on the status and characteristics of current sales orders. "When you start entering orders in Enterprise App Brand Y, you won't be able to do that any more.  You've been able to see that they ordered these patio table to go with this umbrella, and this other table to go with these deck chairs".

[Product lines changed to protect the innocent.]

"But I can only see those relationships in the order entry interface," he pointed out.  "When I print out the sales order, it's not there.  So nobody cares about it. It's okay that we won't have this in the future."

Nobody cares? It's okay? 

He's blissfully unconcerned that there might be different discounts applied to different accessories based on this association, or different suitable styles of umbrellas to go with different patio table models. And what about the ability to analyze your customers' buying patterns, that might be lost, along with this extra data?

I'm biting my nails to the quick, just thinking about it.

Never mind; he's right.  He knows these possibilities I'm raising, and that he acknowledges as rich, are only rich in potential.  If they were real, actual results today, you can bet he would be demanding that today's sales order report be fixed to include them.

He knows that the customer sees (and pays) based on the printed sales order.  The ordered items are manufactured based on the itemized, printed sales order. 

Everything in the data, everything you can get out of the data but that you are not getting out of it today, is just potential benefit.  What you're getting out of the data, your reports and output, is the business result of your app.

As the business slogs through the tedious software and business process conversion, as they cut their conversion losses to negotiate compromises between departments and meet their deadlines, he'll wisely give up potential benefit long before he'll give up one iota of the clarity and benefit (not to mention revenue) he derives from that printed sales order report, however imperfect.

Reports have potential too.

Right now, those sales order reports are actually severely limiting his view of his business, in my opinion, and that's a pity, but it is a testimony to the significance of application output that they shape his perspective so thoroughly, for better or worse 

Two maxims are going through my head right now: "The truth shall make you free" (John 8:32) and "Lies, damn lies, and statistics" (Disraeli).  Reports, output, application results, whatever you want to call them, constantly swing a jittery compass needle between these two poles.  Either way, users steer by them.  They're never unimportant.

Leave a Reply

Your email address will not be published. Required fields are marked *