Administration → Additional Information → Service Level Agreements → Defining SLAs
Service Level Agreements (SLAs) define the level of service that an organization commits to its customers. You can use the SLA feature in SBM Application Administrator to define metrics for tracking these commitments. The topics in the SLA Settings section describe how to do this.
SLAs need to be designed to ensure that performance measurements are meaningful and accurate. If SLAs are defined too broadly, practical usage can cause measurements to be distorted or items could remain in certain states without being noticed. To prevent this, define more granular SLAs (or SLA clauses) that monitor specific phases of an item's lifetime.
The following illustration shows a workflow that tracks the progress of an item.
Use Case 1: Different Paused States
The following table describes two paths that an item could take in the workflow. Different "paused" states are defined for each path.
|Scenario||Start State||End State||Paused State(s)|
|Entire process (SLA 1)||Assigned||Resolved||Waiting, Researching, Deferred|
|Technician needs information before proceeding (SLA 2)||Waiting||Resolved||In Progress, Testing|
When an item is in a "paused" state, time is not counted against the time remaining before the item is in violation of or at risk of violating the SLA. If only SLA 1 monitored the item, the item could remain in the Waiting, Researching, or Deferred states indefinitely. Reports would not indicate a problem, and warning notifications would not be sent. Customer service would be poor, even though it would appear that commitments are being met.
To ensure that an item is not neglected, an SLA should also be defined for the path that starts with the Waiting state. For example, suppose a new item must be completed within three days, according to the high-level SLA (SLA 1). The technician needs critical information before work can start, and moves the item to the Waiting state.
At this point, the item is under SLA 2, which stipulates that an analyst must provide the information within four hours. Because the Waiting state is not a "paused" state in SLA 2, the item will have visibility in reports and notifications if the item stays in this state (or the Researching or Deferred states) too long.
Use Case 2: Re-Opening a Closed Item
In this use case, the elapsed time for the item is three days, because the time since the item was re-opened is added to the previous time.
Copyright © 2012–2015 Serena Software, Inc. All rights reserved.