Searching the Help
To search for information in the Help, type a word or phrase in the Search box. When you enter a group of words, OR is inferred. You can use Boolean operators to refine your search.
Results returned are case insensitive. However, results ranking takes case into account and assigns higher scores to case matches. Therefore, a search for "cats" followed by a search for "Cats" would return the same number of Help topics, but the order in which the topics are listed would be different.
Search for | Example | Results |
---|---|---|
A single word | cat
|
Topics that contain the word "cat". You will also find its grammatical variations, such as "cats". |
A phrase. You can specify that the search results contain a specific phrase. |
"cat food" (quotation marks) |
Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase. |
Search for | Operator | Example |
---|---|---|
Two or more words in the same topic |
|
|
Either word in a topic |
|
|
Topics that do not contain a specific word or phrase |
|
|
Topics that contain one string and do not contain another | ^ (caret) |
cat ^ mouse
|
A combination of search types | ( ) parentheses |
|
Process metrics
Each service desk interaction, change request, incident, or problem record displays metric information when you enable the Service Level Agreement (SLA) component to work with these applications. Thereafter, each new service desk interaction, change request, incident, or problem record has an SLT section that identifies the related SLA and shows the Service Level Target (SLT) performance metrics.
The process information includes:
- Status
- Achieved
- Running
- Breached
- Suspended
- Inactive
- SLT Name
- Agreement Name
- Agreement ID
- From
- To
- Expiration
- Total Elapsed Time
Response time data
Service Level Targets (SLTs) measure response time guarantees in the case of an outage. Service Level Management gathers the following information about response times from SLT records and stores it in the Service Level Agreement (SLA):
- Application name
- Initial state
- Final state
When you view the SLA, Service Level Management displays a complete list of all process and service SLTs and their current status. Service Level Management gathers response data from service desk interactions, change requests, change tasks, incidents, problems, problem tasks, requests and request tasks.
Calculation of Process Target metrics
Based on predefined Process Targets, a record must be handled within the specified period of time. Otherwise, the target is breached. A duration is usually used to measure record handling performance. You can measure the record handling performance of a service provider, an internal group, or a supplier, and calculations can be done either without considering the groups that are assigned to handle a record, or by considering groups that are assigned to handle the record.
Metric calculation without considering assignment groups
When Process Target metrics are calculated without considering assignment groups, no specific group is involved in the calculation. You can specify one of the following methods for the system to calculate the metrics. If a record that is measured by a Process Target is not processed from its initial state to its final state within a predefined duration, the system treats the target as being breached.
-
Using a specified duration
With this method, you specify a duration for a Process Target when you define the target.
To enable the system to use this calculation method, select Interval in the Duration Type field and specify a duration in the Duration box when you define a Process Target.
The duration must be specified in this format: dd hh:mm:ss. In this duration type, one day is counted as 24 hours. For example, if the working hour lasts 8 hours based on the current schedule, and you specify the interval as 1 05:00:00, the duration (24+5=29 working hours) is treated as 3 business days and 5 business hours.
The duration takes effect once a record that is associated with the Process Target enters its initial state.
-
Using the duration specified in the record
With this method, you specify a duration for a Process Target in the record that is associated with the target. For example, you can add a new field in the incident table (probsummary), and then use the specified value in that field as the duration for the Process Target.
To enable the system to use this calculation method, select Duration in Record in the Duration Type field and specify the field that contains the predefined duration in the Field in Record box when you define a Process Target.
Similar to using a specified duration, the duration must be specified in the format of dd hh:mm:ss, and one day is counted as 24 hours in this duration type. The duration takes effect once a record that is associated with the Process Target enters its initial state.
-
Using a calculated duration
With this method, the duration of a Process Target is calculated based on different conditions.
To enable the system to use this method, select Calculation in the Duration Type field when you define a Process Target. You can further choose one of the following conditions.
-
End of business day
You can usually use this condition to specify that a record must be processed to its final state before the end of a business day.
You can optionally specify a buffer period for record handling. For example, if the business day ends at 5:00 pm and the buffer period is 3 hours, records that are submitted before 2:00 pm must be handled before the end of the current business day whereas records that are submitted after 2:00 pm can be handled before the end of the next business day.
To enable this condition, select End of Business Day in the Duration Calculation Method field. If you want to specify a buffer period, type it in the End of Day Window box, with the format of dd hh:mm:ss. If no buffer period is set, the actual end time of a business day that is defined in the schedule is used.
-
End of business week
You can usually use this condition to specify that a record must be processed to its final state before the end of a business week.
You can optionally specify a buffer period respectively for the current business day and for the current business week for record handling. For example, if the business week ends on Friday and you specify that the "End of Week" day as Thursday so as to have one day buffer, records that are submitted on or before Thursday must be handled before the end of the current business week whereas records that are submitted after Thursday and before the end of the current business week can be handled in the next business week. When buffer periods are specified for both the business day and the business week, the "end of business week" calculation is combined with the "end of business day" calculation.
To enable this condition, select End of Business Weekin the Duration Calculation Method field. If you want to specify a buffer period for the business day, type it in the End of Day Window box, and if you want to specify a buffer period for the business week, select a day in the End of Week drop-down list for the system to calculate the buffer.
-
End of business day plus interval (Work Schedule based Expiration)
You can optionally specify an additional period for record handling. This condition can extend the record handling duration by several business days and hours.
The system starts to count the additional period based on the setting of the buffer time. For example, if the business day ends at 5:00 pm and the buffer period for the business day is 3 hours, the system starts to count the additional period of the Process Target from the beginning of the next business day for records that are submitted before 2:00 pm whereas it starts to count the period from the beginning of the third business day for records that are submitted after 2:00 pm.
In this calculation, the length of the actual business day might vary based on the definition of the work schedule, and only business hours are counted by the system, which means that public holidays, vacations, record suspending time, and other non-working time are excluded. The non-working time is added back after regular calculation. For example, if a record handling process is delayed by a public holiday (1 business day), which counts for 3 business hours based on the work schedule, the 3 business hours are added back after the regular calculation.
Consider the following scenario:
- The current work schedule is from 9:00 am to 3:00 pm on Mondays, 10:00 am to 1:00 pm on Tuesdays and Wednesdays, and 9:00 am to 2:00 pm on Thursdays and Fridays.
- The end of business day buffer is 3 hours.
- The additional period for record handling is 2 4:00:00.
- The record is submitted at 11:00 am on Monday.
In this scenario, the system starts to count the additional period from 10:00 am on Tuesday, and Tuesday and Wednesday are counted as 2 business days. The remaining 4 hours of the period are counted from 9:00 am on Thursday. After this calculation, the target expiration time is 1:00 pm on Thursday.
If non-working time is involved, the time is added after the regular calculation above. For example, if Wednesday is a public holiday in the scenario, the system adds the 3 hours (10:00 am to 1:00 pm on Wednesday) back after the regular calculation. Then the new target expiration time is 11:00 am on Friday.
To enable this condition, select Work Schedule based Expiration in the Duration Calculation Method field. Optionally, you can specify a buffer period in the End of business day buffer box, and specify the additional period for record processing in the Additional interval (business hour) box. If no buffer period is set, the actual end time of a business day that is defined in the schedule is used. If no buffer period is set, the actual end time of a business day that is defined in the schedule is used.
-
Service Catalog Item Expiration
With this condition, you specify that the system must use the duration defined in a Service Catalog item as the duration of the Process Target. For this option to take effect, Delivery Targets must be defined for the corresponding Service Catalog item.
To enable this condition, select Service Catalog Item Expiration in the Duration Calculation Method field when you define the Process Target. For more information about how to make the Service Catalog Item Expiration calculation method take effect, see Example: How to make Service Catalog Item Expiration work.
-
Metric calculation for assignment groups
When you define a Process Target for an Operation Level Agreement (OLA) or a Underpinning Contract (UC), you might want to better understand the performance of the groups that are assigned to handle the record. In this case, you can specify to which assignment group the duration of a target applies. Based on your specified option, the system either stops or continues its counting for the Process Target when the record is reassigned among different groups.
Note
- This calculation only applies to Process Targets for OLAs or UCs.
- If multiple groups are involved, they must agree on the same OLA. Otherwise, the targets associated with different OLAs are measured separately.
As vendor/supplier is managed as an external group in Service Level Management, the measurement methods for internal groups and external groups are the same except that internal groups agree on an OLA while external groups agree on a UC. Therefore, the following sections do not differentiate between internal groups and external groups.
Metric calculation for all assignment groups
When this method is used, the system counts the duration of a Process Target together for all the groups that are assigned to handle the record. The counting does not stop when the record is reassigned among different groups.
Consider the following scenario:
- The work schedule is 24x7, and the default time zone of the system server is used.
- The duration of a Process Target is 4 hours.
- The record is assigned to group 1 at 9:00 am.
- The record is reassigned to group 2 at 11:00 am.
In this scenario, as the record has already been processed by group 1 for 2 hours, only 2 hours are left for group 2, and the target becomes breached from 1:00 pm.
The breaching time is different if group 1 and group 2 have different schedules. For example, if the work schedule of group 1 is from 9:00 am to 5:00 pm and that of group 2 is from 1:00 pm to 9:00 pm, group 2 is not working when the the record is reassigned to it at 11:00 am, and thus the record is suspended from 11:00 am to 1:00 pm. The counting resumes when group 2 starts to work at 1:00 pm, and the target becomes breached from 3:00 pm.
To enable the system to use this method, select Total time for all assignment groups from the Duration scope drop-down list.
Metric calculation for each assignment group
When this method is used, the system counts the duration of a Process Target for each individual group that is assigned to handle the record. The counting pauses when the record is reassigned to another group and it resumes when the record is assigned back.
Consider the following scenario:
- The work schedule is 24x7, and the default time zone of the system server is used.
- The duration of a Process Target is 4 hours.
- The record is assigned to group 1 at 9:00 am.
- The record is reassigned to group 2 at 11:00 am.
- The record is reassigned back to group 1 at 2:00 pm.
In this scenario, group 1 uses 2 hours to process the record, and when the record is assigned back, it has 2 hours left before the target becomes breached, which means the breaching time is 4:00 pm for group 1. Group 2 uses 2 hours to process the record, and 2 hours of the target duration is left, which means the target is not breached for group 2 when it processes the record.
To enable the system to use this method, select Total time for each assignment group from the Duration scope drop-down list.
Metric calculation for the current assignment group
When this method is used, the system counts the duration of a Process Target for the group that is currently assigned to handle the record. The counting starts when the record is assigned and it restarts each time when the record is reassigned, including the situation in which the record is reassigned back to the original group.
Consider the following scenario:
- The work schedule is 24x7, and the default time zone of the system server is used.
- The duration of a Process Target is 4 hours.
- The record is assigned to group 1 at 9:00 am.
- The record is reassigned to group 2 at 12:00 pm (noon).
- The record is reassigned back to group 1 at 2:00 pm.
In this scenario, group 1 uses 3 hours to process the record initially. When the record is reassigned back, the system restarts its duration counting for group 1, so the target won't be breached by group 1 until 6:00 pm. As to group 2, it uses 2 hours to process the record, so the target is not breached by that group.
To enable the system to use this method, select Time for the current assignment group from the Duration scope drop-down list.
Monitoring the peformance of an assignment group
When you monitor the peformance of assignment groups, you might be interested in the following two types of targets:
- Response time targets: These targets reflect how soon a group can start processing a record that is assigned to it. Usually it is a period in which the status of a record changes from "open" to "work-in-progress".
- Resolution time targets: These targets reflect how soon a group can resolve a reported issue. Usually it is a period in which the status of a record changes from "open" to "resolved".
As a general practice, you can usually select Time for the current assignment group in the Duration Scope field when you measure the response time targets, because there should be enough time for a group each time when a record it assigned to it.
For resolution time targets, you can usually select Total time for each assignment group in the Duration Scope field, because the total time for each group to resolve an issue is measured individually, and the performances of different groups are comparable.