Reports and their Elements
From Data to Report | Tools versus Results | Daten and Metadata | Search Help versus Report | Structured versus Unstructured | Template versus Snapshot
The following section describes - from a somewhat more technical point of view - the elements of a report as well as the reporting environment. It will clarify, that technology cannot be separated from ergonomics, but that the two both restrict and support each other. Several terms will also be defined here.
- From Data to Report
- Tools versus Results
- Data and Metadata
- Search Help versus Report
- Structured versus Unstructured
- Template versus Snapshot
Résumé: The various aids that help to provide information, can be considerably more beneficial if they work closely with one another and share common functions.
From Data to Report
Many different components influence the creation of a report. It could be said that these define the report:
Data Storage
This is where the business data that is to be reported on when it is analyzed is stored. This data needs to be current and quickly accessible (see also: Warehouse versus Direct Access).
Query
The query determines which data is selected from the data storage, and how several data storages, if possible flexibly definable, are linked together. When creating a query users should be supported so that they can find the required data or metadata easily (see also: Data versus Metadata and Search Help versus Report).
View
The view determines how the data delivered by the query is presented, for example, the criteria according to which it should be condensed, sorted or filtered. The functions available, which should be easy to use and intuitive, decide the extent to which the completed report is geared towards users' tasks, and remove some of their workload.
Modules
In order to keep the layout of a report as flexible as possible, many reporting tools include the option displaying a view that is not a uniform whole, but individual parts of the whole (such as, navigation area, table, graphic and so on), placed separately in the report. As with program interfaces where there are low-level and high-level interfaces, pre-configured module groups also have to be available (and definable) alongside the smallest modules, the biggest of which has to correspond to the whole.
Visual Design
Formats such as colors, fonts, lines, graphics and bitmaps are decided here. They decisively determine the display and can, among other things, simplify or hinder the recording of data. A good tool for creating reports does not only provide the necessary functions here, but also supports users in choosing ergonomic formats and combinations of formats. Therefore, even users who have not been trained in the psychology of perception can create ergonomic reports.
Layout
In the layout, the arrangement of the various parts of the report is specified (modules) or, if necessary, expanded with additional graphical elements (for example, logos). Different reports, that can still also be logically interdependent, are often put together in one format. Typical examples are forms, newspapers and cockpits.
Blurring the Boundaries
These more technical details must be hidden from the user wherever possible. Users specify a report, or to be more precise, a report template (the report itself is created only when the data is read and processed with the template), and are not interested in the various technical elements of it. Transition between the different components and therefore the assignment of technical properties is smooth (see also: Global versus Local Settings). Therefore it has to remain as concealed as possible by a well-designed report creation tool.
Variable Parameters
The parameters that shape a report are not always specified when the report is created. Frequently, at least some of the parameters have to be set when the report is executed, that is, when the report template is filled with data. This can either be done manually or using, for example, a user-specific pre-defined set of parameter values.
Such parameters can also be supplied with values for authorizations, responsibilities and affiliations to certain units' personnel organization. There is also the option of specifying the parameters through another program or report from which the current report has been called up.
What does this mean?
Although a tidy program architecture is indispensable in a good report creation tool, these details do not need to burden users. Indeed, they can actually simplify customizing and personalization expense(especially when making changes later) and allow more flexibility.
Tools versus Results
When reports are mentioned in connection with SAP applications, it can mean three different things:
- The report creation tool, that is, the program with which a report or a report template is created.
- The completed report template, which presents the appropriate data whenever it is called up and therefore continues to create new reports.
- The reports themselves, the data content of which cannot be altered and which provide a snapshot of data at a particular point in time.
Tool
The tool with which reports are created is, in the simplest case, comparable to a paint box. In the most complicated case, it is a programming environment. There are also many steps in between these two extremes,. Therefore, it can be sensible to have different tools for different users (see also: Beginners versus Experts and One Tool versus Several Tools).
Result
The result that is created by the tool can be a report template that must be called up online and shows data valid at the time it is called up, or a complete report that displays data that was valid at the time at which the report was created (see also: Templates versus Snapshots).
Blurring the Boundaries
Whereas previously, a tool-orientated approach was normally used for calling up reports, the document-orientated approach is most often used today. This is, for example, similar to text documents: They used to be called up by starting the text editor and then loading the document into the editor. These days, users can call up a document directly, at which point the appropriate editing tool is automatically started up. Only when a new document is created that does not have a corresponding existing document that can be used as a template, does the editing tool have to be called up directly.
What does this mean?
Users no longer have to think about technical categories such as tool, template and report. They can simply decide on a business-orientated level what it is that they want to see: A report that was created earlier, or current data.
Data and Metadata
Data
In this case, data means the business data about which users want to create reports. This can be completely different types of data from completely different sources (for example, financial data, dates, quantities, costs, allocation and other attributes) that have various sorts of connection with each other.
Metadata
Metadata describes the relationships between sets of data and the properties that the datasets have. This is usually of no interest to the end user during analysis, but plays a fundamental role during the creation and alteration of reports or report templates. It delivers a model of the system's in-built business management that is as consistent as possible. It makes statements about the significance and format of the available business data and about the relationships between datasets.
Blurring the Boundaries
The larger the business data content about which reports can be created and the more metadata available, the more need there is for a repository offering similar functions to those offered for reporting business data.
On the other hand, classification data, for example, builds a kind of metadata system itself. This is not set out by the database or data warehouse suppliers, but is built up by individual customers. Yet the data field search can be made simpler by appropriate classification of the data.
What does this mean?
In the administration, data warehouse modeling and report creation, the same powerful tools are used for finding and organizing metadata, as are used in reports on business data. This improves the overview and makes corresponding tasks quicker.
Search Help versus Report
Search Help
When searching, users are interested in a single value or a set of single values that they are going to reuse for a particular purpose. In reporting, these are, for example, reducing the selection, filtering or highlighting. But these sets of hits can also serve as a basis for creating a worklist (see: Information versus operation) or for running a background job (see: Online Versus Offline).
Report
In a report, users want to obtain an overview of a certain quantity of data that they - and certain processes - have limited by using certain criteria. As was mentioned in Information versus operation, this view can serve not only as a decision-maker, but also as a starting point for other actions.
Blurring the Boundaries
Reports and search facilities have many things in common. Therefore, the hit display of a search help should be operated in a similar way to the completed report (for example filtering and sorting). In principle, the hit display can be interpreted as a report that is used to find and select certain entries.
In the case of complex search help where the amount of hits can be limited, these selection conditions should also show the same functions as report selection screens. Again, it is a case of having a task of a similar nature, suggesting a similar conversion.
This has led to the fact that in certain programs, the search principally takes place via generic or pre-defined reports with limited functions (that are geared to the task).
What does this mean?
It is obviously an advantage if objects can be searched for without having to develop another special search help tool. Moreover, users no longer have to use two different tools for two different tasks. This reduces the amount of time needed to learn about the tools.
Structured versus Unstructured
Structured
In this case, structured information means information that has been traditionally classed as a report. Here, data, characteristics, key figures, assignments and other attributes are presented in table or diagram form. The use of trees, grids, and other graphics is also usual. These structures enable diverse analyses. Reports do not always have to be created individually - a large proportion of report creation can be carried out automatically. Searching, sorting, filtering, highlighting and exceptions can be used as desired on individual attributes.
Unstructured
In contrast, documents that contain, for example, body texts, pictures, films, are unstructured information. They are often stored in different ways and created individually and manually rather than automatically. The search - apart from that of attributes in the document master record or document folders - is usually a free-text search using a text index that has been created with a special indexing program.
Blurring the Boundaries
Now, attributes in structured data can also contain unstructured information. Shorter and longer text attributes, and even longer body texts, are not unusual in practice. Moreover, unstructured documents do not exist in a vacuum, but are usually also linked to structured data (not only by a document master record and document storage).
Moreover, a text document can contain tables and diagrams, and tables in reports often contain cells with body text. Users often want to insert text into their reports that give background information about the displayed data. Here the transition is blurred, and it is unclear what has the higher status in a concrete document: the body text or the tables and diagrams.
As already mentioned in Stand-Alone versus embedding, information is often not useful alone, but needs to be explained by its context. This is, of course, also true for the interaction of structured and unstructured information. Therefore, here too the operation of both types of information should remain as similar to each other as possible.
With information exchange, structured reports, as well as other documents, also have to be exchanged and distributed, and it users have to be able to add comments afterwards, not only on paper. Here it is also important that the information can be assigned in a targeted way within the document. In addition to this, comments that have already been made in the data source should also be accessible, without ruining the view of current data.
This means that reports and (in the case of report creation) their fundamental components, are searched for by attributes and parts as well as by their description. A data source can, for example, be searched for according to its fields or attributes, such as author, as well as by the descriptive text.
Lastly, it is must be said that searching for documents, when not using a text index but using document master record attributes, can be seen as master data reporting (see also: Search help versus Report).
What does this mean?
The interlocking combination of structured and unstructured information allows information to be distributed better and more comprehensively. Moreover, learning and changeover expense is clearly reduced if the breach between them is removed.
Templates versus Snapshots
Templates
A template stores the entire "look" of the report, but not the data. The data is read from the database and added to the layout when the template is called up.
Snapshot
On the other hand, actual reports that can exist both on screen and on paper contain data that is valid at the time of their creation. This is important for archiving, or if data from a particular point in time needs to be kept for come special reason.
Blurring the Boundaries
If, as often happens, reports or report templates are created with a report creation tool (perhaps in a scaled-down version) they can obviously be altered later and used as the basis of further reports or report templates. Often, it is sensible, or even necessary, to change the sorting or outline of a report in order to provide a better overview, or to add more information to explain the data that is displayed.
Thus, there is often little distinction between report templates and reports - each template can in principle be saved with the information that was valid at the time of its creation. As long as the report is not being displayed offline, the data can be updated in order to show a more up-to-date set of information. In cases where current data is not actually needed, the performance is improved, as the current data is only examined when necessary.
What does this mean?
The decision of whether to use a template or snapshot can normally be avoided or delayed. It hardly adds to the employee's workload, if at all.