Chapter 3. Planning Your Report Project

Often, when a new reporting system is available, the most popular approach is to migrate the existing reports from a line of business applications such as the mainframe to the new reporting system selected by the organization. In fact, not too long ago, I performed this exact task when I was architecting a custom .NET solution running on SharePoint 2007 for a client that had been using mainframe reports for the past 10 years.

Until a few years ago, the client was using a batch process that would print reports on paper. Then someone would manually go through the reports to review each page to make sure things added up. Some reports were very long and not user friendly, and some people were only interested in bits and pieces of the report and didn't need the whole print out. The training for a new employee was very long, as each report had nonintuitive names such as the 710 report or the 514-D report. Knowing what report you needed wasn't easy, as you needed to know the report's name and request the report from your mainframe person.

The nonintuitive names of these reports always amused me, as they reminded me of the TPS reports in the comedy film Office Space. But I can assure you it was no joke for employees, since they had to know what was in each report.

As I continued to gather requirements, I was assured by the CFO that a lot of paper and time was wasted with this process, as each report was literally a 500-page booklet. In the last ...

Get Professional Microsoft® SharePoint® Server 2007 Reporting with SQL Server 2008 Reporting Services now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.