.gif){kind=small}
.gif){kind=small}
The report is an overview and analysis of a potential application of e-business to your organization. The report must be written and presented in a professional manner. This must be a written report, not simply a list of bullet points. The report should contain sufficient information and detail to enable a reasonably intelligent, knowledgeable individual to understand what you are saying.
Before you can create a report, you need a plan, and developing a report prototype is a key part of that plan. With the report prototype created, most of the hard work has been done. All that remains is to create the report to specifications using your ‘report generation tool’ (if any).
An easy way to learn how to develop a report prototype is to jump right in and tackle an existing report request. If you are creating the report on behalf of someone else, you should start by spending a little time interviewing the user and make sure the report prototype meets the user’s needs. If you ensure that the user is happy with the report’s design before you begin, there will be no surprises when you deliver the final product.
Report design actually begins before you sit down at the computer and start using any report generation tool. Report design has five basic phases:
Ø Defining the concept
Ø Sourcing the data
Ø Creating the design
Ø Developing and testing the design
Ø Deploying and operating the report
Defining the Concept
“Begin with the end in mind” is the principle applies to report design. Before you can actually sit down in front of a computer and create a report, you must first have some idea or concept of what you want the final report to look like.
Good sources of inspiration are any existing reports or spreadsheets you are currently using. It is always good to have a starting point for your report concept. The easiest way to develop and communicate your report concept is to create a prototype, or mock-up, of the report you want to create. You can use a word processor, a spreadsheet, or the low-tech option of pen and paper, but you should try to make the prototype of your report as complete as possible. This will help you later when you are trying to determine the feasibility of creating the report that you want.
A good way to get users thinking about what their own reports could look like is to bring along printed copies of sample or existing reports you have available. While there is not a hard and fast set of questions you should ask users during this phase, the following list should help you get started:
o Who will use this report?
o How often should it be run?
o What subset of data should it include (year to date, current month, one state, all states, and so on)?
o What information would you like to see in the report?
o What is the title of the report?
o What type of report should be generated (column-based report, mailing labels, form letters, statements, and so on)?
o Will the user be prompted for any information?
o What grouping or sorting is required?
o Do any fields need to be calculated?
o Are there any business rules that apply to these calculations?
o How will the report be disturbed (hard copy, exported to Excel, and so on)?
o Is the running of the report likely to interfere with the performance of the database (in other words, should the report be scheduled to run after hours)?
Sourcing the Data
With a prototype in hand, the next step is to determine where the data for your report actually resides. Is it stored in a database, a log file, or a mainframe file? After you have determined the general location, you need to find the database or system administrator responsible for that particular database or system. Armed with the database or file schema (showing the big picture of where all of your data is stored), the database or system administrator should be able to tell you exactly where the data is located.
A common problem is that the data you want to include in your report may not exist. Your accounting system, for example, may not have the capability to track budgets. Therefore, producing a report comparing actual sales to budgeted sales may be difficult. You should also keep an eye out for any fields that need to be calculated and determine whether those calculations should occur on the database level.
With the notes from your meeting in hand, go to your database or system administrator and find out where the data resides for your report. During this discovery, the administrator should be able to provide you with a data dictionary and/or entity-relationship diagram for your database or application. If possible, get a copy of both the data dictionary and entity-relationship diagram, as they will prove invaluable in the report development process.
It is also at this point that your database or system administrator can advise you on the feasibility of the report you want to create. For instance, the user may want a report that shows ten years worth of historical sales data, but it may not be feasible to run a report to add up each and every sale over a ten year period. Your database administrator may need to create a summary table, stored procedures, or other specialized data structure to make reporting on this information possible.
The goal of this phase of report design is to learn where the data for the report is held, so you may want to note the table and field names required, as well as how the tables are joined together.
Creating the Design
After creating a prototype and determining your data source, the next step is to design the report. The best report design is one that is completed first on paper and is then re-created using the report generation tool. During the design phase, you want to revisit your prototype report and, given what you know about the database at that point, indicate which of the fields in your report are going to come from the database, which fields are going to be calculated, and what formula are to be used in those calculations. You should also have a good idea about how the data is organized, what grouping and sorting are required, and what records need to be select to get the results you need.
With both your notes from your meeting with the user and the information gleaned from your database or system administrator, you are now ready to sit down and create the design of your report.
During this phase, try to create a prototype that is as specific as possible. Where you can, show all of the elements of the report accurately. If you want the column headings centered and the columns themselves left-aligned, mark this on your prototype. As reporting needs grow, there may be a number of people creating reports for users. Giving them a clear road map to follow makes things easier all the way around.
During this time, you also should consult the user again to ensure that the report design and content are on track with what the user originally asked for. Again, gaining the user’s approval of the report prototype will ensure that no surprises occur when you deliver the final product.
Developing and Testing the Design
Finally, with the design completed on paper, it is time to open Report generation tool and get down to business. After you have laid the groundwork, the actual report design process should be quick and simple after learning the skills in the manual of the tool used. After the initial report development is complete, you should test your report on a number of different platforms in a number of different situations. If you are distributing your report as part of a web application, try to preview the report on a number of different computers or operating systems. Note any performance issues and revisit your report design to see if you can make any performance enhancements.
If you have created a report that prompts the user for start and end dates, try entering bad dates, the same date, or even some text in those prompts. You need to be prepared to handle any situation that a user may encounter.
Deploying and Operating the Report
As a final step in the report design process, you need to consider how your report is going to be used. Will users want to export the report? How does the report design translate when you export to Microsoft excel or Word? Try to export the report yourself. You may need to revisit your report design based on the results of your exporting attempts.
Will users be able to modify the report? Are your formulas, naming and coding conventions easy to follow? Again, you may need to modify the report design based on your answers.
Finally, when the report is in production, you need to monitor the operation of the report to ensure that the report performs as expected and that it is still relevant. Many organizations think that report creation stops when the report is handled to its users. On the contrary, the report design process should be on going throughout the life cycle of the report, with continual analysis to find ways to enhance the information presented and value to the data.
Presentation of Reports
Naturally, for presentation you may want to choose a graphics device that generates high-quality graphics, with color if you can use that. For example, pen plotters with drafting-quality pens drawing on good paper or on special transparency material can give good results. A high-resolution raster terminal with a good hardcopy device may also be useful; particularly pens drawing on good paper or on special transparency material can give good results. A high-resolution raster terminal with a hardcopy device may also be useful, particularly if it can generate 35mm slides directly.
Getting attractive plots for presentation may also involve you in special choices of graphics parameters; for example, to choose character sizes, line textures, colors or plotting symbols that carry your message vividly.
Report Design Template Overview
To help you get started with the report design process, this includes a number of report design templates that will guide you in creating a report.
Standard Report Example
The standard report is used the majority of the time and allows you to create list reports and to add grouping, sorting, summaries, formulas, and so forth. You also can create reports for analysis using the Standard Report format (such as a report that responds to the request “Show me my top ten customers”), add graphs, and apply predefined styles to your report
Form Letter Example
The form letter format is used to create reports that combine database information with text you enter or import. Using the Form Letter format, you can create form letters, statements, invoices, and so forth that seamlessly merge information from your database (similar to the mail-merge feature found in Microsoft Word and other word processors).
Form Example
This format can be used to print information on existing forms used by your organization. Using the Form format, you can underlay a scanned image of the form that will be used when printing, allowing you to design the report directly on top of the form. With this method, you can align the fields in your report to match the form that you use for printing. After you finish creating the report, you can remove the underlying image, and your report will print correctly on the forms every time.
Cross- Tab Example
A cross-tab report is a data presentation format that closely resembles a spreadsheet. The cross-tab example can help you create a cross-tab report that has rows and columns that can be stacked on top of each other to provide a summarized, hierarchical view of your data. In addition to rows and columns, a cross-tab report also has summarized fields that allow you to quickly read the report for the information you require.
Sub Report Example
A sub report is a report inserted within a report and can be used to display two or more disparate sets of information or to join two or more data sets that do not share a common key. For example, you might use a sub report to show sales information for your organization next t sales information from a particular segment, such as retail. The data for the two sections comes from different data sources and is totally different, but you can use the sub report format to create a sub report that displays the information next to the information on the main report
Another common use of sub reports is to join unrelated data sets. For example, you want to create a report listing all of your organization’s salespeople and then match them to a prospect database that you have purchased. Because the two databases are from different companies, they probably will not have much in common. Using a sub report, you can pick a field in the two databases that is similar (such as a region or a state field) and use that to match the data sets.
References:
http://www.dotnetcharting.com/
http://www.globfx.com/products/swfchart/
http://www.businessobjects.com/product/catalog/crystalreports/
Contributed by Rasma @ Software Associates