Reporting processes - scary stuff

My excuse for my recent blogging hiatus is that I was kicking off a project (or three) with a new client - a securities firm in Vancouver. Rather than spend time expelling ideas, it was time for me to sit, listen and learn. It seems that deluge of incoming information in one direction stopped too much coming back out in the form of this blog. So now that we are all refreshed, its time for me to restart the outpourings - with a thought or two on 'reports'. Hmm, interesting stuff, all those numbers printed on pages of paper - I can't wait to hear (you might be saying to yourself with a forced smile). Hold on though...

In previous lives I have worked directly with electronic reports management tools, either selling, implementing or defining a strategy for the product. Although essential in an ECM vendor's stack, the tools rarely got much attention despite the obvious benefits they could offer customers:

1. Reduce costs printing and storing paper reports
2. Simplify the distribution of reports to consumers of the information
3. Secure notes and reviews of the reports, with a far more effective audit trail

These are just three of the many advantages that can be seen from diverting the flow of reports from real printers to a virtual printing environment that generates an on-screen representation of the original data. There are many other clever features of electronic reports management that allow the reports to be split up automatically based on text on certain pages, and indexed so that a quick database search could pull a specific piece of information (such as a customer statement) from the thousand upon thousands of pages collected each print run over the years (you've seen this with the pretty PDFs of your credit card statement online). But what happens when the report is just that - a report?

As I have been seeing on my travels, the reports generated for back office operations are often not a print-stream from a mainframe that really represents documents such as statements going to customers. They actually live up to their name and are just what they claim to be - reports: a point in time snapshot of data. Examples are: the commissions owed to your agents; the trades made in the previous 24 hours; the status of credit on customer accounts for the last week. From an audit or regulatory standpoint, these snapshots show you are paying attention to your business in a way that a dynamic query of your database can not (things change in databases, therefore generating a realistic point-in-time snapshot is often hard, ineffective or inaccurate).

Storing these reports is easy enough. Replicating what some of them are used for in the business is harder. As I have seen, it takes a real technical accountant to review a securities trading report, ensuring that there are not exceptions or compliance issues. The markups these professionals make in the review process are hieroglyphics to the untrained eye, and essential evidence to the regulators. This is something that traditional reports management software would struggle to handle - allowing someone to rapidly and naturally mark up a report in 5 hours over the course of a day.

Why do I tell you this? Because the obvious technology approaches do not fit every requirement once you really take a look at the issues. Reports management tools will not solve all the issues with real reports. I don't have an answer today. One proposal is to implement more automated solutions for spotting exceptions and helping the technical accountants work more on those exceptions than the 99.9% of things that aren't issues. But that's a challenge for somebody else. For the next week or two, those reports are going to get printed, marked up and stored with paper-cuts included.

My excuse for a blogging hiatus is over. The one way valve is broken, and information is ready to flow both ways again. Watch out!

A post from the Improving It blog