Cisco Prime Service Catalog 12.0 Reporting Guide
Bias-Free Language
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.
- Updated:
- December 1, 2016
Chapter: Generating Reports
- Configuring Client Browsers to View a Report in Excel Format
- Modifying User Preferences to View Reports
- Creating Reports and Queries
- Using Standard Reports
- Creating Custom Reports
Generating
Reports
This chapter contains the following topics:
- Configuring Client Browsers to View a Report in Excel Format
- Modifying User Preferences to View Reports
- Creating Reports and Queries
- Using Standard Reports
- Creating Custom Reports
- Accessing Custom Reports and Queries
Configuring Client Browsers to View a Report in Excel Format
Some users may report an issue with attempting to view a report in Excel format. The Excel screen pops up briefly and then disappears. To address this issue, add the Cognos Server URL to the Local Intranet zone of the client browser:
Modifying User Preferences to View Reports
Cognos offers two ways of viewing the reports and folders, represented by icons at the top right of each page. The selected view is highlighted.
 |
The “Details View” includes a brief description of each report. |
 |
The “List View” is the default view. Once you become familiar with the reports, folders, and their contents, you may want to switch to this view, which simply lists the contents of the current folder, as shown below. |
Rather than setting this view manually, the Preferences page allows you to set preferences that are used whenever you use the Reporting module. To set preferences, click the My Area link to the top-right of the menu bar, then My Preferences.
The General tab of the Set Preferences page appears.
Entries at the top of the page allow you to change the default view (List or Details) and to further customize that view.
Entries at the bottom of the page pertain to the user's location/locale. The time zone is used when scheduling reports. The default time zone is the time zone where the reporting server is located. In a distributed implementation, users need to set the time zone to their current location in order to easily schedule reports to be run.
There is no support for rendering of non-English form data or facts table content at this time. The product and content languages should be set to the default language which is English.
Prebuilt Reports Inventory
Service Catalog reports (available in the top-level public folder Service Performance Reports), and the folder in which each is located, are summarized in the table below.
The Service Authorization and the Service Delivery reports include any ad-hoc tasks that were initiated in the authorization and service delivery moments, respectively. They do not include any tasks that were part of requests that were cancelled, either by the user or by a service team manager cancelling delivery of the request.
|
Report Title |
Folder |
Description |
|---|---|---|
|
Aging of Requests by Performer |
Daily Request Management |
Effective for investigating or reporting on the number of open and late tasks for an individual |
|
Aging of Requests by Queue |
Daily Request Management |
Effective for investigating or reporting on the number of open and late tasks for a queue |
|
Authorization: On-time % by Customer |
Service Authorization Performance |
Effective for investigating or reporting on the authorization on-time performance by a customer (OU) |
|
Authorization: On-time % by Performer |
Service Authorization Performance |
Effective for investigating or reporting on the authorization on-time performance by individuals |
|
Authorization: On-time % by Queue |
Service Authorization Performance |
Effective for investigating or reporting on the Authorization on-time performance by queues |
|
Services by Dictionary |
Service Design Details |
Administrative report for managing the use of dictionaries |
|
Functional Positions |
People, Roles & Groups |
Administrative report which lists all functional positions |
|
Groups by Organizational Unit |
People, Roles & Groups |
Administrative report which lists groups and shows their Organizational Unit |
|
Groups by People |
People, Roles & Groups |
Administrative report which lists People and shows their groups |
|
Organizational Units by Group |
People, Roles & Groups |
Administrative report on groups and their organizational units |
|
Organizational Units by People |
People, Roles & Groups |
Administrative report on people and their organizational units |
|
Organizational Units by Queues |
People, Roles & Groups |
Administrative report on queues and their organizational units |
|
People by Groups |
People, Roles & Groups |
Administrative report listing people and their groups |
|
People by Organizational Unit |
People, Roles & Groups |
Administrative report listing people and their organizational units |
|
Queues by Organizational Unit |
People, Roles & Groups |
Administrative report listing queues by organizational unit |
|
Service Delivery: On-time % by Performer |
Service Delivery Performance |
Effective for evaluating or comparing the performance of individuals in performing their work |
|
Service Delivery: On-time % by Queue |
Service Delivery Performance |
Effective for evaluating or comparing the performance of queues in performing their work |
|
Service Delivery: On-time % by Service |
Service Delivery Performance |
Effective for evaluating the on-time performance for services and their related tasks |
|
Service Pricing Details |
Service Design Details |
Administrative report for managing the pricing information for services |
|
Service Volume: Request Activity by Service |
Service Volumes & Activity |
Effective for measuring and monitoring total service request activity within service groups |
|
Service Volume: Request Activity Details |
Service Volumes & Activity |
Effective for investigating or reporting on the status of individual service delivery transactions |
|
Service Volume: Request Activity Summary |
Service Volumes & Activity |
Effective for measuring and monitoring total service request activity within specific reporting periods |
|
Service Volume: Request Trend by Service |
Service Volumes & Activity |
Effective for measuring and monitoring service request activity trends by service group and calendar quarter |
|
Services by Service Team |
Service Design Details |
Effective for managing expenditures for services against an established budget |
Creating Reports and Queries
Detailed instructions on using Query Studio and Report Studio are in the User Guides supplied by IBM/Cognos, which are available from the vendor’s web site. This section addresses concerns specific to the Service Catalog data mart and the framework that allows query and report builders access to that data mart.
Both tools allow equivalent access to the query subjects and query items exposed in the custom package. Reports or queries are created simply by dragging items from the Insertable Objects pane at the left of the page to the Reporting pane. As each item is added to the report, Cognos automatically adjusts the underlying SQL that is used to retrieve data for the report. To do so, Cognos relies on the relationships defined in the custom package through which the data mart is exposed. This package includes relationships between the dynamically defined dictionary-based dimensions and all fact tables. These relationships rely on database inner joins; information on a task or requisition (from the corresponding fact query subject) will appear in a report containing dictionary-based information only if the dictionary was used in the service to which the requisition or task applies.
Because Query Studio is an easier tool to use than Report Studio, especially for new users, We recommend that users start with Query Studio. If they are unable to implement the functionality for the required report, they may save the query and subsequently edit and enhance it in Report Studio; all queries created in Query Studio are upward compatible with Report Studio.
In particular, the following types of requirements should be implemented using Report Studio:
- Reports that need to display a percent of total, for example, percentage of tasks of a particular type that were on time or late.
- Reports that need to list requisitions with dictionary data, but have the dictionary data blank for services in which the dictionary was not used; this can be implemented via master-detail reports in Report Designer.
- Reports with complex filters, for example, in which either one or the other of a condition may apply for data to be included in the report. (In Query Studio, all filters are logically AND’ed, so that all conditions must be satisfied for a row to be included in the report.)
Using Standard Reports
The Standard Reports Package contains denormalized base data tables. These tables are used as the basis for the prebuilt reports as well as providing summary data tables for populating the KPIs.
Each of these tables is a standalone entity—it is not possible to join a table to any other in order to create a new report or modify an existing report. If you need to make modifications to a standard report, your best bet is to construct the desired report from scratch, using the Service Catalog data mart and the Custom Reports package. This section gives some hints on how to do this for some of the reports, using Ad-Hoc Queries (Query Studio) to construct the query.
People, Roles, and Groups
The reports in the People, Roles, and Groups folder can be duplicated by using the query subjects in the Organizations folder (Person, Group, and Organizational Unit) and the Queue dimension. The reports are fairly straightforward and can be generated by inserting the appropriate items on the report and grouping as desired.
For example, the Organizational Units by People report might look like this:
The report definition (viewable under Manage File in Query Studio) to build this report would look like the following figure (with a group specified on the Person Full Name, and the filter defined as a “Search and Select” filter).
The same query items, with a different set of filters, are used in the “People by Organizational Unit” report:
Service Design Details
Like the reports in the People, Roles, and Groups folder, those in the Service Design Details folder are fairly easy to produce. Simply choose the desired items from the Dictionary and Service dimensions and group as desired.
For example, the “Services by Dictionary” report as produced by Ad-Hoc Query could look like this:
To exactly duplicate the appearance and behavior of the standard report, the following activities are required in Report Designer:
Request Management
The Request Management folder includes two aging reports, which break down tasks into buckets, based on the number of days late the task is. The buckets are defined as 1–3 days late, 3–7 days late, 1–2 weeks late, and over 2 weeks late. The reports group the late tasks either by queue or by performer.
This report is essentially a pivot report. The metric that is pivoted is the age of the open task. To produce this report:
- Place the appropriate attributes/dimensions on the report work area—the queue organization; the queue name; and the task name for the Delivery Tasks fact.
- Compute the age of the task by taking the difference (in days) between the current date and the task due date.
- Set up a custom group for the four aging buckets.
- Pivot the report using the custom group (Age) as the metric.
Service Volumes and Activity
The Service Volumes and Activity reports give summary information on the number of services requests started within a particular time frame, and the current status of those requests. For example, the Service Volume: Request Activity by Service looks like this:
Because of the complexity of the computations (tallying up the counts based on the status of the request), this report needs to be implemented in Report Designer.
Creating Custom Reports
The Advanced Reporting module provides the ability to write ad-hoc queries and reports. The module includes three options:
- The Home page provides shortcuts for running the Standard reports, without having to choose the Reporting module from the Service Catalog drop-down menu.
- The Ad-Hoc Reports tab provides access to IBM Cognos Query Studio, for writing queries against the data mart.
- The Report Designer tab provides access to IBM Cognos Report Studio, for writing professional quality reports against data mart.
Users must be granted appropriate permissions to access the Ad-Hoc Reports and Report Designer options.
This section offers instructions on how to access the Advanced Reporting Module and detailed information on the contents and structure of the Service Catalog data mart.
- Accessing the Advanced Reporting Module
- Dimensions
- Facts and Star Schemas
- Organizations
- Data Mart Dimensions
- Service Bundles
- Data Mart Facts
- Organizations Folder
- Service Bundle Folder
Accessing the Advanced Reporting Module
To use the advanced reporting capabilities, from the Service Catalog drop-down menu, choose the Advanced Reporting module.
The Home Page of the Advanced Reporting option displays the three predefined public folders.
- The Reports folder offers an alternate path to the prebuilt reports accessible as part of the Reporting module. Custom-designed report views and any new reports created via Ad-hoc Reports or Report Designer will also typically be stored on subfolders of the Reports folder.
- The remaining folders (Custom Reports Data Model, Standard Reports Data Package ) are packages which are used by Report Designer and Ad-Hoc Reporting, allowing you to build queries and reports against the Service Catalog data mart.
Typically, you will click a tab corresponding to the Ad-Hoc Reports or Report Designer option. These options start the Cognos Query Studio and Report Studio components respectively. You will then be asked to choose which of the two reporting package you want to use.
To access the data mart, choose the Custom Reports Data Model by clicking on the name. If you are using Report Designer, you will then be asked to specify the type of report you would like to create. Specify a list (it is the easiest). If you are using Ad-Hoc Reports, Query Studio automatically opens for a list report. The Custom Reports package appears in the left-hand pane, labeled “Insertable Objects”.
The data mart is configured as a dimensional model.
- The basic transactional data in a dimensional model is called a fact. Facts in the data mart include the tasks, requisitions, and effort entry. Each fact may include several measures—numeric quantities. For example, the estimated duration of a requisition is a measure, as is the actual duration.
- Each fact has relationships to one or more dimensions – descriptive attributes that can be used to choose or filter the rows in the related fact. For example, dimensions that describe the task-based facts include the task performer as well as the date the task was closed. Dimensions, in turn, are usually shared across multiple facts. For example, the service dimension may describe both a task and a requisition.
- Each fact, together with its related dimensions constitutes a star schema.
- In addition to star schemas, the Custom Reports Package includes other tables to provide complete coverage for potential reports and queries users might need to formulate about form, dictionary and service-based data, as well as the organizational structure at the site.
The dimensions and facts are grouped within the corresponding folders. In addition, the Organizations folder holds data on the organizations, groups, and people in use at the site. The Service Bundles folder holds data on the service bundles and child service which were associated to the parent service to form the bundle.
As you expand the
folders, all of the dimensions and facts become visible. Each object designated
by the
icon is a query subject which groups a
related set of fields or query items. Expanding the query subject will show its
query items.
A query item can be a unique identifier, an attribute or a measure/metric, as indicated by the icon to the left of the item name:
 |
Attribute |
 |
Metric |
Metrics are numbers which can be used in arithmetic expressions. By virtue of an item being defined as a metric, its value can be aggregated (for example, averaged, totaled or counted) to provide report totals or subtotals when the report or query has several levels or groups. In addition, metrics can be used in a wide variety of arithmetic, analytic, and percentage calculations, as specified by the report designer and provided by the Cognos tools.
A list of all query subjects and the query items which comprise each subject, with a description of each query item, is given in the tables at the end of this section.
Dimensions
The Custom Reports Package includes the following types of dimensions:
- Static dimensions are available in all installations, and are listed directly under the Dimensions folder. These dimensions describe customers, performers, dates, and other information related to tasks and requisitions.
- The DictionaryData folder lists all dimensions based on dictionaries which were specified as Reportable, and were therefore loaded into the data mart. Each reportable dictionary is available in the DictionaryData folder. Each dictionary query subject includes all fields in the dictionary, whether they were hidden or not in any or all services. One or more dictionary dimension can be joined with any fact, providing a flexible reporting and filtering mechanism.
- The ServiceData folder contains all services which were specified as Reportable, and were therefore loaded into the data mart. Each service query subject contains all fields in all dictionaries used in the service, provided that the number of fields allowed per service is not exceeded; if so, the dictionaries and fields are omitted from the service. The service query subjects are not, strictly speaking, dimensions; they should not be combined with a fact for reporting purposes. Instead, using a service query subject as your report object provides a shortcut to reporting on all dictionaries and fields in the service.
- The Service Bundles folder contains all the service bundles and the child services which were associated to service bundles. These dimensions cannot be joined with any facts or dimensions which are available in the package.
You generally use the dimensions in conjunction with a fact table, to include additional data about the fact in your query or report, or to filter the output of the query or report by detailed criteria.
Facts and Star Schemas
This section describes the facts and star schemas.
Requisitions – ServiceRequestFact
The ServiceRequest fact holds data related to requisition and the requested services. The date and duration attributes that are included in the fact are for the service request and not for the requisition (a shopping cart that can contain multiple requests). This fact includes metrics about the performance—whether the request was in compliance with its SLA, for example, or its actual or estimated duration, as well as links to all dimensional information about the request, including its initiator, the customer and any reportable dictionaries included in the service ordered.
A star schema diagram showing the ServiceRequest fact and related dimensions is shown below.
Task-Based Facts
The Service Catalog data mart provides five views of the task-based facts. Two of these views (RequisitionTaskFact and ServiceTaskFact) are provided primarily for backward compatibility with previous versions of Advanced Reporting. They may freely be used; however, they do not contain some metrics and counts which may be useful for many reports.
Each view is optimized by grouping certain sets of tasks. Reports and queries which need to interrogate tasks will perform best if they are based on the task-based fact which best meets the report's requirements.
Task-based facts are summarized below.
|
Fact |
Usage/Description |
|---|---|
|
All Tasks |
All tasks performed during fulfillment of a service request. |
|
Authorization Tasks |
All authorization and review tasks. |
|
Delivery Tasks |
All delivery tasks, including ad-hoc tasks. |
|
RequisitionTask Fact |
All tasks which are performed at the requisition level and not at each service task level. These include financial authorizations, departmental authorizations, and departmental reviews. If sites do not use any of these authorization types, this fact table is empty. This query subject is provided primarily for backward compatibility with previous versions of the Service Catalog data mart. |
|
ServiceTask Fact |
Data related to service-level tasks. These include service group authorizations and reviews; service delivery tasks; and ad hoc tasks. This query subject is provided primarily for backward compatibility with previous versions of the Service Catalog data mart. |
When creating a report or query, always use the Fact table whose contents best match the type of tasks to be included in the report. Fact table contents are summarized in the table below.
|
|
Financial Authorization |
Department Authorization |
Department Review |
Service Group Authorization |
Service Group Review |
Delivery Tasks |
Ad-Hoc Tasks |
|---|---|---|---|---|---|---|---|
|
All Tasks |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
✓ |
|
Authorization Tasks |
✓ |
✓ |
✓ |
✓ |
✓ |
|
|
|
Delivery Tasks |
|
|
|
|
|
✓ |
✓ |
|
ServiceTask Fact |
|
|
|
✓ |
✓ |
✓ |
✓ |
|
RequisitionTask Fact |
✓ |
✓ |
✓ |
|
|
|
|
The same dimensions are related all task-based facts with the exception of the “Service”, which is not relevant to RequisitionTask facts. A star schema diagram showing the relationships is shown below.
The ServiceTaskFact and RequisitionTaskFact facts have been deprecated. It is recommended that report designers use other facts to build all custom reports.
Effort Expenditure – TaskEffortEntry Fact
The TaskEffortEntry Fact holds data related the effort expended for each task. Effort entry is available by category, such as labor or material. Since some implementations have opted to not require effort entry, there may be no data available for this fact.
Organizations
The Organizations folder contains information on the groups, organizations, and people configured at the site. Query subjects in this folder cannot be joined with dimensional or fact data, but only with each other. Corresponding query items can be found in query subjects within the Dimensions and Facts folders.
Data Mart Dimensions
All query items (attributes of both facts and dimensions) available in the Dimensions folder of Custom Reports package are summarized in the tables in this section. This list does not include any dictionary or service-based form data, which, of course, will vary from site to site.
Customer
The customer dimension describes the person who is the recipient of the service which was ordered.
The semantics of the query items which comprise this query subject may be modified if custom mappings to Person attributes have been applied as part of directory integration. The descriptions given below are the defaults that are expected by Organization Designer. Some of these fields may be blank, if they are not used at a particular site.
|
Query Item |
Description |
|---|---|
|
CustomerID |
Customer ID |
|
Customer Full Name |
Full name of the customer, in First Name Last Name format |
|
CustomerFirstName |
First name of the customer |
|
CustomerLastName |
Last name of the customer |
|
CustomerOUID |
Organizational Unit ID of the customer's home OU |
|
CustomerOUName |
Name of the customer's home organizational unit |
|
CustomerBuilding |
Building in which the customer is located |
|
CustomerBuildingLevel |
Building level/floor on which the customer is located |
|
CustomerOffice |
Office of the customer |
|
CustomerCubic |
Customer cubicle number |
|
CustomerStreet1 |
First line of the street address of the customer |
|
CustomerStreet2 |
Second line of the street address of the customer |
|
CustomerCity |
City in which the customer is located |
|
CustomerStateProvince |
State in which the customer is located |
|
CustomerZip |
Zip code of the customer |
|
CustomerCountry |
Country in which the customer is located |
|
CustomerLoginName |
Login name of the customer |
|
CustomerEmailAddress |
Email address of the customer |
|
Work Phone |
The work phone of the customer |
|
Cust_SupervisorID |
ID of the customer's supervisor |
|
Supervisor Full Name |
Full name of the customer's supervisor, in First Name Last Name format |
|
Cust_SupervisorFirstName |
First name of the customer's supervisor |
|
Cust_SupervisorLastName |
Last name of the customer's supervisor |
|
Cust_SupervisorEmail |
Email address of the customer's supervisor |
|
Cust_SupervisorLoginName |
Login name of the customer's supervisor |
|
Customer Status |
Customer status; valid values are “Active” and “Inactive” |
Dictionary
The dictionary dimension may be used to describe the dictionary in which a form field was entered.
|
Query Item |
Description |
|---|---|
|
DictionaryID |
Dictionary ID |
|
DictionaryName |
Name of the dictionary |
|
DictionaryGroupID |
ID for the dictionary group to which this dictionary belongs |
|
DictionaryGroupName |
Name of the dictionary group |
|
DictionaryServiceItemFamily |
Service Item family name for a particular dictionary |
|
Is Reportable |
Flag that indicates whether the dictionary is designated as reportable (1) or not (0). Reportable dictionaries will have corresponding query subjects under the “DictionaryData” folder. |
Keyword
The keyword dimension may be used to list keywords associated with a particular service.
|
Query Item |
Description |
|---|---|
|
KeywordID |
Unique identifier for the keyword |
|
Keyword |
The word or words by which catalog users can search for services to order |
Performer
The performer dimension describes the person who performs a task. This includes delivery, ad-hoc, and authorization/review tasks.
The semantics of the query items which comprise this query subject may be modified if custom mappings to Person attributes have been applied as part of the directory integration process. The descriptions given below are the defaults that are expected by Organization Designer.
Queue
The queue dimension describes the queue to which a task was assigned.
| Query Item | Description |
|---|---|
| QueueID | ID of the queue to which the task was assigned |
| QueueName | Name of the queue |
| Queue Status | Status of the queue – “Active” or “Inactive” |
| QueueOUID | Identifier of the organizational unit which services the queue |
| QueueOUName | Name of the organizational unit of the queue |
| Work Phone | Work phone of the queue |
| Email Address | Email address of the queue |
Requestor
The requestor dimension describes the person who ordered the service.
The semantics of the query items which comprise this query subject may be modified if custom mappings to Person attributes have been applied as part of directory integration. The descriptions given below are the defaults that are expected.
|
Query Item |
Description |
|---|---|
|
RequestorID |
ID of the person who requested the service |
|
Requestor Full Name |
Full name of the requestor, in First Name Last Name format |
|
RequestorFirstName |
First name of the requestor |
|
RequestorLastName |
Last name of the requestor |
|
Requestor Status |
Status of the requestor – “Active” or “Inactive” |
|
Work Phone |
The work phone of the requestor |
|
RequestorOUID |
Organizational Unit ID of the requestor's home OU |
|
RequestorOUName |
Name of the requestor's home OU |
|
RequestorBuilding |
Building number/name in which the requestor is located |
|
RequestorBuildingLevel |
Building level/floor of the requestor |
|
RequestorOffice |
Office of the requestor |
|
RequestorCubic |
Requestor cubicle number |
|
RequestorStreet1 |
First line of the street address of the requestor |
|
RequestorStreet2 |
Second line of the street address of the requestor |
|
RequestorCity |
City in which the requestor is located |
|
RequestorStateProvince |
State in which the requestor is located |
|
RequestorZip |
Zip code of the requestor |
|
RequestorCountry |
Country in which the requestor is located |
|
RequestorLoginName |
Login name of the requestor |
|
RequestorEmailAddress |
Email address of the requestor |
|
Req_SupervisorID |
ID of the supervisor of the requestor |
|
Supervisor Full Name |
Full name of the supervisor, in First Name Last Name format |
|
Req_SupervisorFirstName |
First name of the supervisor |
|
Req_SupervisorLastName |
Last name of the requestor's supervisor |
|
Req_SupervisorEmail |
Email address of the requestor's supervisor |
|
Req_SupervisorLoginName |
Login name of the requestor's supervisor |
Service
The service dimension includes a hierarchy (service team, service group, service) for organizing data relating to the service for which a requisition was ordered or a task was performed. Service attributes can be used in conjunction with any fact table to qualify or filter the fact data.
|
Query Item |
Description |
|---|---|
|
ServiceID |
Service ID |
|
ServiceName |
Name of the service |
|
Description |
Brief description for the service |
|
ServiceGroupID |
ID of the service group to which the service belongs |
|
ServiceGroupName |
Name of the service group to which the service belongs |
|
ServiceTeamID |
ID for the service team responsible for the service |
|
ServiceTeamName |
Name of the service team responsible for the service |
|
ServiceStandardDuration |
Standard duration specified in the service definition |
|
ServiceDurationUnits |
Units in which the standard duration is displayed |
|
ServiceHoursPerBusDay |
Number of hours per business day |
|
EstimatedCost |
Estimated cost for the service |
|
PublicationDate |
Publication date for the service |
|
ExpirationDate |
Expiration date for the service |
|
IsInactive |
Flag that indicates whether the service is active (0) or inactive (1) |
|
Is Reportable |
Flag that indicates whether the service is designated as reportable (1) or not (0). Reportable services will have corresponding query subjects under the “ServiceData” folder |
|
Is Orderable |
Flag that indicates whether the service is designated as orderable (1) or not (0) |
|
Price |
Service Summary Price |
Service Bundles
The Service Bundles query subject provides access to all Service Bundles in the application repository.
|
Query Item |
Description |
|---|---|
|
Service Bundle ID |
Unique identifier for the service bundle |
|
Service Bundle Name |
Name of the service bundle |
|
Description |
Brief description of service bundle |
|
Service Group Name |
Name of the service group to which the service bundle belongs |
|
Service Team Name |
Name of the service team responsible for the service bundle |
|
Standard Duration |
Standard duration specified in the service bundle definition |
|
Durations Units |
Units in which the standard duration is displayed |
|
Hours per Business Day |
Number of hours per business day |
|
Price |
Service bundle price |
|
Service Bundle Status |
Status of the service bundle |
|
Is Reportable |
Flag that indicates whether the service bundle is designated as reportable (1) or not (0). Reportable services will have corresponding query subjects under the “ServiceData” folder |
|
Is Orderable |
Flag that indicates whether the service bundle is designated as orderable (1) or not (0) |
TaskType
The task type dimension may be used to provide the description of a task type.
|
Query Item |
Description |
|---|---|
|
TaskTypeID |
Task Type ID |
|
TaskTypeName |
Description of the task type |
Task types are listed below.
|
ID |
Task Type |
|---|---|
|
0 |
Delivery Task |
|
1 |
Financial Authorization |
|
2 |
Departmental Review |
|
3 |
Departmental Authorization |
|
4 |
Service Group Authorization |
|
5 |
Service Group Review |
|
6 |
Ad-hoc Task for Delivery |
|
7 |
Ad-hoc Task for Authorization |
|
8 |
Ad-hoc Task for Review |
CalendarClosedDate
The CalendarClosedDate dimension provides a hierarchy for structuring queries about the date a requisition or task was closed. Using query items in this dimension provides an easier way to filter or group by dates, rather than having to choose a complete date and use an expression to extract, for example, just the month or week you are interested in.
|
Query Item |
Description |
|---|---|
|
ClosedDateID |
Date a task or requisition was closed, in the format YYYYMMDD; for example, 20081225 |
|
Full Date |
Complete date in the format dd-Mon-yyyy; for example, 25-Dec-2008 |
|
Day Month Name |
The month and day of the month; for example, Dec-25 |
|
Week of Year |
Week of the year, in the format Weekn-yy; for example Week1-08 |
|
Calendar Year Month |
Month of the calendar year in yyyy-nn format, where yyyy is a four-digit year and nn is a number between 1 and 12; for example, 2008-12 |
|
Calendar Year Quarter |
Quarter of the calendar year in yyyy-Qn format, where yyyy is a four-digit year and n is a number between 1 and 4; for example, 2008-Q4 |
|
ClosedWeekDay |
Day of the week on which the item was closed, where 1=Sunday and 7=Saturday |
|
Day of Week Name |
Day of the week (Sunday-Saturday) on which the item was closed |
|
ClosedDateWeekStartDate |
Starting date (Sunday) of the week in which the item was closed |
|
ClosedDateWeekEndDate |
Ending date (Sunday) of the week in which the item was closed |
|
ClosedDateMonth |
Month in which the item was closed |
|
ClosedDateMonthName |
Name of the month in which the item was closed |
|
ClosedDateQuarter |
Calendar quarter in which the item was closed |
|
ClosedDateYear |
Calendar year (YYYY) in which the item was closed |
CalendarDueDate
The CalendarDueDate dimension provides a hierarchy for structuring queries about the date a requisition or task was due. The same date formats are available as for the CalendarClosedDate dimension.
CalendarScheduledDate
The CalendarScheduledDate dimension provides a hierarchy for structuring queries about the date on which a task which was allowed a scheduled start date was actually scheduled to start. If no explicit scheduled start date was specified, the scheduled date is the same as the start date.
The same date formats are available as for the CalendarClosedDate dimension.
CalendarStartedDate
The CalendarStartedDate dimension provides a hierarchy for structuring queries about the date a requisition or task was started. This is the actual start date.
The same date formats are available as for the CalendarClosedDate dimension.
Data Mart Facts
The query subjects in the Facts folder provide information about the tasks and service requests logged via the application service catalog.
- ServiceRequestFact (Requisitions)
- Task-Based Query Subjects
- RequisitionTaskFact
- ServiceTaskFact
- TaskEffortEntryFact
ServiceRequestFact (Requisitions)
The ServiceRequestFact provides information about services ordered. Folders group metrics for On-Time and Request Status Counts.
|
Query Item |
Description |
|---|---|
|
RequisitionEntryID |
Unique ID for the service request |
|
RequisitionID |
Unique ID for the requisition (shopping cart) in which the service was requested |
|
ServiceID |
Service ID for the service |
|
Service Bundle ID |
Service ID of the service bundle |
|
Requestor ID |
Unique ID for the service requestor (initiator of the service request) |
|
Customer ID |
Unique ID for the customer (recipient) of the request |
|
Status |
Current status of the service request |
|
Quantity |
Service quantity that was requested |
|
Price |
Price of the service |
|
Started Date |
Date the service request was started |
|
Due Date |
Date the service request is/was due |
|
Closed Date |
Date the service request was closed |
|
Started DateTime |
Date and time when the service was requested |
|
Due DateTime |
Date and time when the service delivery is due |
|
Closed DateTime |
Date and time when the service request was closed |
|
Default Duration |
The configured duration required to deliver the service; specified in hours |
|
ActualDuration |
The actual duration taken to deliver the service |
|
ServiceOntimeFlag |
Flag that indicates whether the service request was completed on time (1) or late (0) |
|
ServiceStandardComplianceFlag |
Flag that indicates standard compliance for the service request |
|
Completed On-Time Request Count |
1 if the current request was completed on time, zero (0) otherwise; count is automatically totaled when requests are grouped on a report |
|
Completed On-Time Percentage |
Percentage of requests that were completed on time |
|
Standard Compliance Percentage |
Percentage of requests that were completed in compliance with their SLAs |
|
Submitted Count |
Number of requests submitted; since requests are not added to the data mart until they are submitted, this will always equal the number of requests |
|
Cancelled Count |
Number of requests that were cancelled by the user |
|
Completed Count |
Number of requests whose delivery plan has been completed |
|
Ongoing Count |
Number of requests submitted but not yet closed |
|
Rejected Count |
Number of requests rejected by an approver |
|
Delivery Cancelled Count |
Number of requests whose delivery was cancelled by a service manager |
|
Service Request Status |
Current status of the service request |
|
Billed Organizational Unit |
Organizational unit to be billed for the service |
|
Submitted Date |
Date the request was submitted |
Task-Based Query Subjects
The All Tasks, Authorizations Tasks, and Delivery Tasks Facts have the same component query items.
- All Tasks provides information about all tasks, including all delivery tasks, reviews and authorizations, performed to complete a service requisition.
- Delivery Tasks provides information about delivery tasks, including ad-hoc tasks.
- Authorization Tasks provides information about reviews and authorizations.
|
Query Item |
Description |
|---|---|
|
Task ID |
Service Task ID |
|
Task Name |
Name of the service task |
|
Display Order in Service |
The order in which the task is executed within the service’s workflow |
|
Task Type ID |
Type ID of the task |
|
Requisition ID |
Corresponding Requisition ID of the task |
|
Requisition Entry ID |
Corresponding Requisition Entry ID of the task |
|
Service Bundle ID |
Unique ID for the service bundle in which this task is performed, if it was executed as part of a child service |
|
Service ID |
Unique ID for the service for which the task is performed; null (blank) for requisition-level approvals, which do not pertain to a particular service. |
|
Performer ID |
Unique ID of the performer who performed the task |
|
Queue ID |
ID of the queue to which the task is assigned |
|
Status |
Current status of the task |
|
Started Date Time |
Date and time when the task will be/was started |
|
Due Date Time |
Date and time when the task is/was due |
|
Completed Date Time |
Date and time when the task is/was completed |
|
Scheduled Date Time |
Date and time when the task is/was scheduled to be completed |
|
Planned Effort (Hours) |
Planned effort specified for the task in the service definition |
|
Planned Duration (Hours) |
Configured duration for the task to be performed, in hours, as specified by the service designer |
|
Actual Duration (Hours) |
Actual duration taken for the task as performed, in hours, as calculated by the system, based on the customer's calendar |
|
Performer’s Actual Duration (Hours) |
Actual duration taken for the task as performed, in hours, as calculated by the system, based on the performer's calendar |
|
Completed Task Count |
Indication of whether a task has been completed; 1 if the task has been completed, 0 if it has not |
|
Completed On-Time Task Count |
Indication of whether a task was completed on time; 1 if the task was completed before its scheduled completion date, 0 if it was not |
|
Completed On-Time Percentage |
Percentage of tasks completed on time; for each individual completed task, this is either 100% or 0%; the computation applies as tasks are summarized |
|
Late Open Task Count |
Number of tasks still open that are late |
|
Standard Compliance Percentage |
Percentage of tasks that were completed within their specified duration |
RequisitionTaskFact
The RequisitionTaskFact provides information about requisition-level authorization and review tasks performed to complete a service requisition. This query subject is provided for upward compatibility with legacy systems only; the All Tasks, Service Delivery Tasks, or Authorizations Tasks query subject should be used, as appropriate.
ServiceTaskFact
The ServiceTaskFact provides information about delivery tasks, ad-hoc tasks, service group authorizations and service group reviews performed to complete a service requisition. This query subject is provided for upward compatibility with legacy systems only; the All Tasks, Service Delivery Tasks, or Authorizations Tasks query subject should be used, as appropriate.
TaskEffortEntryFact
The TaskEffortEntryFact provides information about effort expended in the performance of a task.
|
Query Item |
Description |
|---|---|
|
EffortEntryID |
Unique ID for the effort entry |
|
ServiceTaskID |
Unique ID identifying the task on which this effort was expended |
|
EnteredDate |
Date the effort was logged |
|
Description |
Description of the effort |
|
Category |
The category in which the effort was expended |
|
ContributorID |
Person ID of the person who performed the task for which effort entry was required |
|
Contributor Full Name |
Full name of the contributor in First Name Last Name format |
|
ContributorFirstName |
First name of the person who performed the task for which effort entry was required |
|
ContributorLastName |
Last name of the person who performed the task for which effort entry was required |
|
EffortQuantity |
Number of units of effort expended |
|
EffortCost |
Total (extended) cost of the effort entry – unit cost multiplied by quantity |
|
EffortUnitCost |
Unit cost of each unit of effort |
|
UnitType |
The unit of measure for the effort entry |
Organizations Folder
The Organizations folder contains query subjects which allow you to report on organizations, groups, people, and the relationships among these entities. These query subjects cannot be joined to the transactional (fact) data. Instead, you should use the organization or person information in the appropriate dimension—Customer, Performer, or Requestor—to include such items in reports that also include data on tasks or service requests.
Group
Groups provide a container for disparate sets of people or organizations, allowing you to assign permissions or tasks to a single group rather than to the individual group members. To view members of a group, or see the groups with which a person was affiliated, a report could contain items from the Group and Person query subjects.
|
Query Item |
Description |
|---|---|
|
Group Name |
Name of the group |
|
Group Status |
Status of the group – Active or Inactive |
|
Parent Group Name |
Parent of the group |
|
Description |
Description of the group |
Person
The Person query subjects provides access to all people in the repository, regardless of the role (Customer, Performer, Requestor) they have played in the processing of service requests.
|
Query Item |
Description |
|---|---|
|
Person ID |
ID of the person who requested the service |
|
Person Full Name |
Full name of the person, in First Name Last Name format |
|
First Name |
First name of the person |
|
Last Name |
Last name of the person |
|
Home Organization Unit Name |
Name of the person's home OU |
|
Building |
Building number/name in which the person is located |
|
BuildingLevel |
Building level/floor of the person |
|
Office Number |
Office of the person |
|
Cubicle Number |
Person cubicle number |
|
Street Address1 |
First line of the street address of the person |
|
Street Address2 |
Second line of the street address of the person |
|
City |
City in which the person is located |
|
State or Province |
State or province in which the person is located |
|
Zip or Postal Code |
Zip or postal code of the person |
|
Country |
Country in which the person is located |
|
Login Name |
Login name of the person |
|
Email Address |
Email address of the person |
|
Supervisor ID |
ID of the supervisor of the person |
|
Supervisor Full Name |
Full name of the supervisor, in First Name Last Name format |
|
Supervisor First Name |
First name of the person's supervisor |
|
Supervisor Last Name |
Last name of the person's supervisor |
|
Supervisor Email |
Email address of the person's supervisor |
|
Supervisor LoginName |
Login name of the person's supervisor |
Organizational Unit
The Organizational Unit query subjects provides access to all organizations in the repository.
|
Query Item |
Description |
|---|---|
|
Organizational Unit Name |
Name of the organizational unit (OU) |
|
Description |
Description of the OU |
|
Organizational Unit Typ0e |
Type of OU – Service Team or Business Unit |
|
Organizational Unit Status |
Status of the OU – Active or Inactive |
|
Parent Organizational Unit |
Parent of the OU, if an organizational unit hierarchy has been set up |
Service Bundle Folder
The Service Bundle folder contains query subjects which allow you to report on service bundles, associated child service and the relationship among these entities. A service bundle consists of one parent and one or more child services.
Service Bundles
The Service Bundles query subject provides access to all Service Bundles in the application repository.
|
Query Item |
Description |
|---|---|
|
Service Bundle ID |
Unique identifier for the service bundle |
|
Service Bundle Name |
Name of the service bundle |
|
Description |
Brief description of service bundle |
|
Service Group Name |
Name of the service group to which the service bundle belongs |
|
Service Team Name |
Name of the service team responsible for the service bundle |
|
Standard Duration |
Standard duration specified in the service bundle definition |
|
Durations Units |
Units in which the standard duration is displayed |
|
Hours per Business Day |
Number of hours per business day |
|
Price |
Service bundle price |
|
Service Bundle Status |
Status of the service bundle |
|
Is Reportable |
Flag that indicates whether the service bundle is designated as reportable (1) or not (0). Reportable services will have corresponding query subjects under the “ServiceData” folder |
|
Is Orderable |
Flag that indicates whether the service bundle is designated as orderable (1) or not (0) |
Service
The Service query subject provides access to all child services which are part of a service bundle.
|
Query Item |
Description |
|---|---|
|
Service Bundle ID |
Unique identifier of the service bundle |
|
Service ID |
Unique identifier of the parent service of the service bundle |
|
Service Name |
Name of the service |
|
Description |
Brief description of the service |
|
Service Group Name |
Name of the service group to which the service belongs |
|
Service Team Name |
Name of the service team responsible for the service |
|
Standard Duration |
Standard duration specified in the service definition |
|
Durations Units |
Units in which the standard duration is displayed |
|
Hours per Business Day |
Number of hours per business day |
|
Price |
Service price |
|
Display order in Bundle |
Display order in the service bundle |
|
Service Status |
Status of the service |
|
Is Reportable |
Flag that indicates whether the service is designated as reportable (1) or not (0). Reportable services will have corresponding query subjects under the “ServiceData” folder. |
|
Is Orderable |
Flag that indicates whether the service is designated as orderable (1) or not (0) |
Accessing Custom Reports and Queries
When report designers create custom reports or queries, they may save them either to the Public folders (the Reports folder is the root public folder) or to their private folder (“My Folder”). Reports saved to the private folders are runable/accessible only by the person who developed them.
Reports saved to the public folders are accessible/runable by any person who has a role that allows access to the reports. These inherited permissions can be overridden Cognos Administration options, which allow the Report Administrator to remove permissions to execute a report from the standard roles and assign that permission to any person or custom role that has access to run reports.
In addition to being run from the Reporting module folders, reports are also accessible via hyperlinks. Service designers may embed appropriate links in service descriptions, e-mail notifications or other areas of the application. The format of the link is:
http://<CognosServer Name>/crn/cgi-bin/cognos.cgi?CAMNamespace=TrustedSignOn&b_action=xts.run &m=portal/report-viewer.xts&method=execute &m_obj=/content//report[@name='<ReportName>']
For more information, see Using Reports.
Feedback