Reports and their Environment
Stand-Alone versus Embedding | Information versus Operation | Batch versus Online | Mailing versus Subscription
Reports are always incorporated in some way into the working environment. The following examines which dependencies should be taken into account here, but also the possibilities presented.
- Stand-Alone versus Embedding
- Information versus Operation
- Batch versus Online
- Mailing versus Subscription
Résumé: Through the integration of reports in the informational landscape into operational business and into general communication paths, in combination with automated analyses, many work processes will clearly be optimized.
Stand-Alone versus Embedding
Stand-Alone
For a long time, on screen reporting meant that only one report was displayed at a time. In the best cases this consisted of several parts (for example, diagrams and tables). Since many reports also have to give a good overview of a large amount of data, a stand-alone report is still often chosen as the best method of displaying reports.
Embedding
However, portfolios of reports are often created from printouts. These portfolios consist of various reports with related contents. Here, the different reports are not always distributed on separate pages. A more substantial overview is actually often given, as a result of the fact that you can view data from different reports at a glance.
This advantage has also found its way into reports on-screen. In particular, the fact that it is considerably easier to bring together information from different sources on the Web and display it together, has prepared the way for 'cockpits' and 'newspapers'. Since there is less space remaining here for individual reports, the author has to, of course, concentrate on only essential information for these pages.
Blurring the Boundaries
Often this excerpt of data is, however, does not provide the reader with enough information. Further data is required, which describes the displayed information more clearly and clarifies questions that arise from assessing the overview. Therefore, it offers to supply, from reports that are relatively less interactive in the 'cockpit', the jump to stand-alone reports with extended navigation options. The reports can, when necessary, also display larger amounts of data and can, in turn branch out into other reports.
Therefore, another aspect of embedding, not yet mentioned above, is addressed: Stand-alone reports are also linked, thus making it possible to jump to and from "portals", "cockpits", other reports and even processing transactions (see: Information versus Operation). Even for determining (and removing) the causes of distinctive features, a quicker link to additional sources of information is a great help, whether this supplies a larger overview, reveals further details, or allows you to access other data from the current context.
If - as addressed in From Data to the Report and in Search Help versus Report - a report consists of several components that are perhaps reports themselves, the distinction between a report from components and a composition of individual reports is pointless, at least from the user's point of view and if necessary therefore, also has to be hidden by the tools.
What does this mean?
A meaningful and clear composition of data from different sources allows users to grasp important information and its causes, at a glance, information for which they would otherwise have to navigate through various programs and screens. This helps users to absorb information more quickly and relieves the strain on their short-term memory.
Information versus Operation
Information
In earlier products the distinction between operative and more informative transactions was usually fairly clear. Reports either delivered an overview of a (possibly) large amount of data or provided more flexible methods of analysis and more alternative views of the data than operative transactions.
Operation
In contrast to this, operative transactions worked mainly on single objects and often delivered only one view of the data, namely one that optimized data entry and checking.
Blurring the Boundaries
However, there have also been common features here for a long time: Firstly, access to a processing task is usually information-driven. A good working environment supports this, by facilitating the jump directly, from the reports that deliver information, to processing transactions. In this way, the report is a kind of portal.
It is also especially important with planning transactions, that you can examine the data directly, during processing or simulation, from different perspectives. At the very least it must be possible to navigate quickly between the processing view and various analytical views. Even complex evaluations are required in part, before the data (if necessary, even irreversibly) is saved permanently in the database.
And thirdly, in more and more areas, the worklist is important, that is, a number of objects, selected beforehand that have to be worked on. Again, we can differentiate between two cases: The worklist can feed a kind of workbench, from which different operations are executed according to each object. Users have such standardized central access into a defined working environment, from within which individual activities can be carried out (because they are information-driven) more quickly and more purposefully.
On the other hand, the worklist can also be the basis for mass activities. One activity (or, if necessary, several activities) is executed on all the objects in the worklist, in this case. Using the end results, the activity can then be produced again in another report, which, if necessary, releases a further activity. In this way a circle is formed from which you can construct a complex workflow.
What does this mean?
By linking the provision of information with operational business, you can automate specific mass activities and tackle other activities more purposefully. This takes the load off employees and accelerates the work procedures that are still carried out by hand.
Batch versus Online
Batch
At the start of the computer age, reports could only be printed out. Later, the screen display on character-based screens was added. This display was of limited size because of the smaller screen segment - especially since the display was usually static. Large quantities of data can still usually only be selected in batches; and a large printout gives a better overview of this data than the screen.
Online
Conversely, the on-screen display offers more flexibility: You don't have to wait for the printout from the printer, you can try out views without creating large mountains of paper and in addition, you can jump around between reports and transactions (see also Stand-Alone versus Embedding). Creating ad-hoc reports with simple tools is only really of interest since the introduction of tools, which create and execute reports online.
Blurring the Boundaries
Often, users want to select and process larger quantities of data using online reports. Nevertheless, they do not want to have to wait a long time for this. In many cases here, they prefer to calculate reports in batches and then display them online. It is not always the case that users have scheduled an overnight report. More often, users need to be able to create ad-hoc reports in the background, while continuing to work during formatting. The report can then be called up a short time after the end of the batch job (for example, following an automatic notification).
A further - probably even more important - application field, in which batch and online reports work together, is the alarm function: Reports are executed in the background and the data is checked against pre-defined exception conditions. Exceptions that occur produce a message or start a workflow via, among other things, the report displayed online, in which the exception occurred.
Even such scenarios, which can relieve employees of a lot of time-consuming work, in that they do not always have to check their data, must naturally be easily definable. In practice, this requires such exceptions and regular checks to be specified not by IT personnel, but by area specialists. These specialists recognize the exact requirements of their area and are able to communicate these to the system. This speeds up the creation process and relieves the strain on IT personnel. However, it must still be ensured that the system is not overloaded with batch jobs.
What does this mean?
Combining batch data selection with online reporting accelerates the speed of work, in that the user does not have to wait so long for the report to be displayed. In addition, the user is relieved of time-consuming routine tasks (for example checking and monitoring certain data and transactions) using alarm functions.
Mailing versus Subscription
Mailing
Many reports are not only used by employees, but by other people as well. Therefore, users must be able to exchange them, and, if possible, not only on paper, but also electronically. This includes not only the need to send out the finished report with its data, but also, to exchange report templates and modules amongst one another. With completed reports (and in part, report templates as well) the user often wants to add specific comments before they are sent out (see: Structured versus Unstructured).
Subscription
On the other hand, there are also many situations, in which information has to be accessible to a group of readers, whose range is not known to the author. It therefore has to be possible to make the report or the report template accessible to a group of potential interested readers. These potential readers can then subscribe to the report or add it to their personal favorites (key word: 'publish and subscribe'). It is especially helpful, if an automatic notification is sent to the user as soon as the report is changed. The alarm function (see also: Batch versus Online) can also be useful in this situation.
Blurring the Boundaries
However, there are also methods of sharing information that lie between these two alternatives. You can send a document out, not only to a specific addressee, but also, for example, to distribution lists. These can either be created by the sender, or be generally accessible, so that interested parties can register themselves on the lists. In addition, in order to reduce the data transfer and so that the user is only dealing with a central document, only links to the document are often sent and not the document itself.
On the other hand, it is often the case that users do not only subscribe to single documents, but whole folders. In this case, the user does not only have access to explicitly selected documents, rather all documents created in these folders (if applicable via a link). If the user is now automatically informed of changes, the effect is similar to that described in the previous paragraph for sending a link.
All of these possibilities for exchanging information, which we have long since taken for granted with unstructured documents (for example, text documents), are, of course, just as valid for reports and report templates (see also: Structured versus Unstructured).
What does this mean?
The possibility of exchanging and distributing structured information, as well as unstructured information using different, complementary channels, furthers communication and therefore, co-operation. Particularly in large organizations where tasks, which can no longer be taken on by one person, are distributed among several employees, it is an indispensable aid for coordinating sub-tasks and avoiding massive increases in duplicated work.