Uniformity and Diversity of Reports and Tools
Preconfigured versus Customized | Individual versus Generic | One Tool versus Several Tools
How accurately can software producers anticipate user requirements? At the end of the day, what should be left to the customer or end-user? How can special demands be integrated most effectively with standards? These problems will be addressed in the following points:
Résumé: By choosing the right standards, adaptation to individual demands can be both simplified, and accelerated, considerably. Therefore, the main focus should not be on a wide variety of complete solutions, but on a well-modulated system.
Pre-configured versus Customized
Pre-Configured
As a rule, producers of standard software also offer a (varying)number of standard reports. Especially when there is a large amount of legal, and other format and layout standards to be observed, such reports that are delivered with the software can drastically reduce the software-introduction phase.
But even in other areas, companies - especially those that are too small to be able to assign a large number of employees to creating reports - can profit from having reports that can be used straight away.
Customized
On the other hand, customers have company, departmental and user-specific requirements that cannot be taken into consideration in pre-configured standard reports. Even more than in transactional programs, customers want to create their own reports and, if necessary, do not mind making the additional effort required.
Blurring the Boundaries
For most users, it is a big advantage if there is already an accessible template, or choice of possible templates, on which they can base their reports, rather than starting from scratch. This can save time as the user does not have to redefine every little detail. In addition to this, such templates contain ideas and information on using certain features that cannot normally be easily found in documentation.
Since many companies underestimate the time needed to create reports, the above method can prevent bottlenecks. Therefore, predefined reports and modules have to be delivered in all areas, even in those where they are not expected to be used in their exact form in the customer's operational business.
What does this mean?
The creation of a reporting landscape is accelerated up considerably if templates are provided. This does not mean that individual requirements, for example, on layout, design have to be sacrificed.
Individual versus Generic
Individual
Different applications have different requirements. Different employees have different tasks to complete and different knowledge. In each area, employees want tools that are as efficient as possible and that are geared toward their duties. This also applies to reports. Therefore there is a demand once again for ease and flexibility of making individual adjustments.
Generic
On the other hand, the concept "If you know one, you know them all" has also been proven to be useful. Users do not want to have to get used to a new layout every time they use a report - they prefer to have certain general standards. Moreover, they want to be able to carry out changes in the same way wherever possible and do not want to have to get used to another user interface.
Blurring the Boundaries
The creation of a library with generic modules of differing granularity that can be combined as required, and if necessary, adapted to meet special requirements, could provide a solution to this problem. This enables users to create reports quickly and easily, retaining a sense of uniformity yet not preventing individual solutions (see also Flexibility versus Layout and Pre-configured versus Customized).
What does this mean?
The creation of reports, and therefore the supply of required information, is made quicker. Despite individual tailoring, there is still some common ground that enables users to get to grips with a new report more quickly.
One Tool versus Several Tools
One Tool
As we have seen, the topic of reporting covers a vast area. Depending on for whom, when, by whom and in what way reports are being created, there are completely different requirements for creating the reports and also for displaying them. Just as it is not sensible to try to build a vehicle that can be used as a lorry and as a sports car, so there cannot be a tool that is as well suited for media-geared high level presentations as for ad-hoc analyses.
The requirements are too numerous and too varied to be grouped together in one tool, and still be easy to understand and work efficiently. In reporting it is also important to have tools not only for specialists who work with them regularly, but also for the occasional and/or untrained user.
Several Tools
On the other hand, it appears that using several specialized tools also has its dangers - especially if these tools are operated in different ways. When, as is often the case, a user works with different types of reports, each tool must be learned separately. This can require quite considerable effort. Moreover, if programs are operated in different ways, users need to pay more attention to what they are doing, so that they do not mix up the programs.
Blurring the Boundaries
One way round the dilemma is to provide several specialized tools whose common functions work in the same way. This means that users do not always need to go to as much effort to finding out about the program they are currently working with. The users do not need to know whether the common functions are realized within the programs by generally used modules or not. The obvious advantage of this is that maintenance is reduced and the user interfaces do not diverge. However, this solution is not always possible, because of program architecture. Moreover, it is important to ensure that the intersection of the functions offered is not disjunct, that is, that there are many functions that are available in several of the specialized programs. Only in this way do users not have to decide between different tools that offer some, but not all, of the functions they need for one actual report.
This can be compared to a toolbox in a workshop: A hammer does not need to be suitable for planing down a plank, but when hammering a nail into the wall, the procedure should be similar to that of hammering a nail into a plank. Moreover, according to what is being built, a new, different tool is chosen from a large range of tools. Two or three tools removed from the existing toolbox would not be the optimized choice. There would be unnecessary tools among them (because they are not needed) or, worse, tools that are important for the job would be missing.
A beginner would at first use tools that are easy to use, but as they gained experience they would want to use more powerful tools. In the same way, report creation tools should provide obvious easy functions and not so obvious advanced functions that are nevertheless accessible. Moreover, these advanced functions must be easily available for experts, or at least there must be the option of making them easily available (by customizing or personalizing the program).
Especially if the person who creates a report is not the person who executes it, it should be possible to make some functions available and some not available in a modular system, and to influence how these functions are offered.
What does this mean?
Users who create reports, as well as those who analyze them, do not have to learn how to use as many different user interfaces. Nevertheless, different functions can be made available individually in the completed report.
Conclusion
As we have seen, many distinctions are significant for orientation purposes, but a hindrance if they create boundaries in reporting software. The key phrase is: Flexible integration. We have seen where this integration is possible both in principal and in practice today, or in the near future. The program designer's task is to turn these possibilities into reality, so that users are equipped to deal with the demands of today's fast-moving and globalized society.