Information Technology Reference
In-Depth Information
While implementing an OTS product, there is a general tendency to
downplay the effort needed to provide the correct set of reports. The
discussion with end users typically results in a line item in the implemen-
tation contract that reads “12-15 reports will be provided.” Sometimes,
more qualified statements such as “Reports for departmental heads and
executive management,” or “seven snapshot reports, four drill-down
reports, and up to four statistical analysis reports” are added. However,
both of these are inadequate descriptions.
Reports have high visibility in an organization, and are often the
whetstone on which a new system is judged that the acceptance of the
system often hinges on this. If the report requirements are not properly
understood in the beginning of the project, and later it becomes apparent
that changes to data model or complex graphical representations must be
introduced, the entire project timeline can lie in jeopardy. Unless the OTS
product is being used as a replacement for an existing application (in
which case the reporting needs are better known), it is important to get
detailed inputs on reports. These inputs include the organization, access
control needs, textual or graphical nature, information to be presented,
and usage patterns.
Reports are also a quick way of obtaining insight into what an OTS
product provides and supports. If one wants to make sure that the OTS
product will meet one's requirements, it is advisable to use reports as one
of the starting points. It is possible that the required information may be
available in the data model but not included in the standard reports. It is
also likely that the information or concept may not be handled by the
product at all. Reports can reveal these aspects and raise doubts (questions
of OTS product suitability in the organization) fairly quickly.
Like all other customization, one will need to draw a line somewhere.
Building a report customization editor within one's OTS product may be
interesting from a customer point of view, but it is not very practical.
Most customers have a resistance to learning a new language, although
it may be fairly simple. They will, instead, ask one to create more reports
(or customize existing ones) “since the tool already exists and you are
experts in making it happen.” It may be better to provide an interface to
a standard report writer (the most common one in the target market
segment) that the customer can use to create and deploy reports to their
liking. One must be careful of the hidden costs of such report writers and
deployment environments because the customer must bear the burden of
their respective licenses.
