The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter contains the following topics:
Cisco Prime Service Catalog comes with a dedicated reporting environment for business intelligence. Reporting allows you to execute reports, which are presented as tabular or graphical representations of selected data. Cisco Prime Service Catalog Reporting Solution offers two modules for business intelligence:
The Reporting module is bundled with a basic Service Catalog license. The Reporting module provides a set of prebuilt reports on service design, organizational entities, and on transactions (requisitions and tasks) processed through Service Catalog. This module also provides a set of Key Performance Indicators (KPIs), charts which can be configured to appear on each user's reporting dashboard. The following sections discuss capabilities provided by the Reporting module:
Reporting allows you to execute reports, which are presented as tabular or graphical representations of selected data. High-level reports now include multiple levels so that you can drill-down into more detailed views.
The Advanced Reporting module may be licensed as an add-on to a basic Service Catalog license. The Advanced Reporting module includes a data mart for Service Catalog, as well as tools for building simple queries and more complex reports based on data in the data mart.
Advanced Reporting provides complete analysis capabilities, user-defined reports, and prebuilt data marts, to allow for greater visibility and control over IT business management. Business value metrics provide in-depth insight into the quality of IT service and financial data.
You can also use Advanced Reporting to define and customize your own reporting content. Business analysts may author simple queries to create Ad-Hoc reports, while report developers may use the Advanced Reporting applications to design more detailed technical reports.
Workflow for Reporting consists of various phases:
Service Catalog comes with a dedicated reporting environment for business intelligence. The environment consists of multiple components, each of which is optimized for a particular task or set of users. These components are listed below. The environment consists of multiple components, each of which is optimized for a particular task or set of users. These components are listed below.
These reporting capabilities are seamlessly integrated into the Service Catalog framework, but are implemented using tools from the IBM Cognos Series 10 Business Intelligence (BI) solution toolset. These tools are summarized below.
This section describes the architecture of the Service Catalog reporting solution. It can be read by anyone curious about how the Cognos components are used and the role each plays in the solution. It can safely be skipped by those interested primarily in how to use the Service Catalog reporting solution to run the prebuilt reports supplied in the Standard Package or in generating their own ad-hoc reports or queries.
In general, it is not best practice to allow users to run reports in the same environment in which a transactional system such as Service Catalog is operating. The resource requirements for running reports, ad-hoc queries, and other in-depth analyses are vastly different from resource requirements for running a transactional system that responds acceptably to online users. Therefore, data that forms the basis for reports and in-depth analyses is typically extracted from the transactional system and loaded into an environment dedicated and optimized for reporting.
The Service Catalog dedicated reporting environment consists of two packages, whose contents and usage are explained in detail in the rest of this chapter.
The Standard Reports Package supports the prebuilt reports and KPIs. A variety of output options provide information on task-, service-, and requisition-based measures and trends. In addition, reports on the structure of the Service Catalog data, including persons, organizations, service teams, and service groups, are available. All data used in the prebuilt reports is also available in the Custom Reports package. Over time this package is merged with the Custom Reports package.
The Custom Reports Data Package provides a dimensional model which allows ad-hoc reports on task, service and requisition-related data. In addition to the measures and attributes available in the Standard Reports package, data entered by users into the customized service forms configured at each site is available. This “form data reporting” (FDR) provides visibility into all attributes of all dictionaries and services which the service designers have designated as “Reportable”.
The Standard Reports Package consists of a set prebuilt reports and key performance indicators (KPIs) that are supplied with Service Catalog and the database tables required to support generation of these reporting objects. These prebuilt objects meet many business unit requirements for the reports generated from operational data.
The database which supports the Standard Reports Package contains both detail tables and summary tables.
The detail tables provide a denormalized view of the database. Each table provides all the data that appears on a corresponding report. This means that running each report is optimized, so no report needs to access related data in lookup tables. It also means, however, that these tables cannot be combined in a report with other tables, since there are no relationships between the tables: each table is a complete, denormalized view of one type of fact about the OLTP system, to the specified level of detail. Further, no drill-up or drill-down, to different levels of detail, is possible.
The summary tables contain aggregated or summarized data. Presummarizing data eliminates processing delays that would otherwise occur if summary reports needed to aggregate data in real-time, in response to a report request. As for the detail tables, each summary table should be used only for its dedicated reports or KPIs—no summary tables can be joined to other tables to support ad-hoc reporting requirements.
The prebuilt reports that are included in the Standard Reports Package are created using the Report Studio tool and included in the Reporting module. The default report display format is set to HTML; but this delivery format, as well as other runtime parameters, can be modified when the reports are run. If the reporting solution includes Report Designer, users are able to view the definitions of the prebuilt reports and, if desired, modify the definition or create new reports to better meet corporate requirements.
The service Key Performance Indicators are generated using JFreechart API’s (JFreechart is not part of the Cognos product suite, but is open source software). The charts are generated on demand, by reading from the summary data tables created for each KPI.
The Advanced Reporting module allows users to build custom reports and queries from data in the Service Catalog data mart, capturing data from Service Catalog.
The Service Catalog Data Mart is based on the Custom Reports Data Model package. This package gives users access to a data mart which includes service, task, requisition and effort-related information, such as the task performer or the duration of a task. The custom reports package differs from the standard package in important ways:
A metric is a numeric quantity which can be aggregated. It is a measure which provides data you can use to identify and analyze IT service ordering, delivery trends, and problems.
Metrics enable you to:
Metrics and attributes in the data mart are derived using the computations explained in the table below.
In the way that many customers’ services are implemented, the name of the person who is the end customer of a service delivery is stored in the order form for the service. This information is not accessible in the Standard Reports Package and its prebuilt reports. So there are two options for registering the customer of the service delivery:
You can choose a service delivery option based on your customer.
This section describes how to measure the performance of individuals.
Tasks can be assigned to individuals or assigned to queues from which individuals can draw work. The data that is available in the Standard Reports Package and prebuilt reports (specifically the fields PERFORMERID, PERFORMERFIRSTNAME, PERFORMERLASTNAME, PERFORMEROUID and PERFORMEROUNAME in DM_SERVICETASKDETAIL and DM_AUTHORIZATIONTASKDETAIL) can refer to a person under one of three conditions:
The first condition can be distinguished from the data in the Standard Reports Package. However, the second and third cannot. This means that reports that attempt to measure the performance of individuals will only fairly represent their performance if service teams have very clear and consistent rules about not sharing responsibility for tasks. For this reason, a disclaimer appears on all prebuilt reports that measure the performance of individuals.
Prebuilt reports about the duration of tasks performed during service delivery use the PERFORMERACTUALDURATION measure. This measure takes the performer’s working calendar into account, so that weekends and other nonworking hours are not counted against their time working on the task. Conversely, the CUSTOMERDURATIONOFSERVICE measure makes the calculation taking the customer’s calendar into account, making it an inaccurate measure of the performer’s work.
There are two ways to assess whether the delivery team is performing their tasks well. Both are valid, but they have different meanings and uses:
A solid, customer-focused measurement regime requires BOTH metrics. If you base everything on task duration, you are in effect saying “Who cares what we promised to the customer, as long as we are meeting our internal standards?” On the other hand, focusing only on the dates provides an inaccurate picture of team members’ performance, which does not allow you to make the effective resourcing decisions you need to improve your performance for customers.
The dimensional attributes used in the report packages are derived from the data maintained in the Service Catalog OLTP database. Attributes are summarized below.
Attributes |
Description |
---|---|
Customer* |
The person who is the recipient of the service, either when it is ordered directly by the same person or when the service is ordered on behalf of the customer, and the home organizational unit of that customer |
Billed* |
The organization which is billed for the service. This is the same as the customer for the service unless a different organization is chosen as the Bill To: Customer when the ordered is reviewed (after a request has been saved, but before it has been submitted.) Only an organizational unit that has been designated as Billable can be chosen as the Bill To: Customer. |
Performer* |
The person (and corresponding home OU) who performed the task. See Measuring the Performance of Individuals for more information. |