A Service Level Agreement (SLA) is a business contract that specifies service level expectations around critical infrastructure and business services. Typically, they refer to response, restoration and resolution targets that the Service Desk needs to meet.
Operational level agreements (OLAs) are similar to SLAs, except they communicate internal team-based expectations within specific stages of the Workflow process. Similarly, the obligations of external service providers are specified using Underpinning Contracts (UCs). Unlike an OLA where an appropriate Team Technician is assigned responsibility for servicing a request, it is the responsibility of a Service Level Manager to monitor the performance of the external service provider in relation to the business's expectations as defined in UC Workflow States.
Workflows consist of an Entry State, one or more Transitional States and Exit States. They define the sequence of steps that Service Desk staff can follow when managing customer requests. Within the system, any number of Workflows can be customized for the Incident, Problem, Change, Release and Service Request Management Processes. Each step, or Workflow State, defines the activity, and if relevant the OLA, with Default Team, or UC required to successfully process the request at that step. Only after the nominated Team Technician has successfully concluded the activity does the request get routed to the next appropriate Workflow State. The Workflow is deemed complete once the request enters an Exit Workflow State.
When a request is created it is assigned an SLA, and based on the assigned SLA, a Workflow and Team. Based on the configuration of the assigned Team, a Technician or System User is allocated the responsibility of the task. Within Teams, escalation layers are configured for manual or automated routing of requests. Manual routing through the escalation layers is triggered by a Technician in the request Information screen. Automatic routing through escalation layers is driven by the request's assigned priority relative to the associated SLA response, restoration and resolution targets. For each target one or more percentage triggers can be created for automated reminders, warnings or escalations. When the request is in a Service Level active stage of the Workflow the system monitors the percentage of time elapsed relative the SLA triggers, and when percentage targets are met the triggers are activated. If the SLA response, restoration or resolution time is breached, the request is automatically escalated.
The Service Level Management module allows service level expectations to be mapped to end-to-end business processes. In so doing, the system performs the following Service Level Management validation:
SLA resolution time >= Sum (Workflow States (OLA or UC resolution times)
When validating Workflows, the system disallows adding States to a Workflow that will force the sum of the Workflow State resolution timers for OLAs and UCs to breach the SLAs resolution timers. In such situations, the system will warn the service level manager to either increase the SLA resolution targets or select a more appropriate UC or OLA that will fall within the SLA targets.
Log into Novell Service Desk as a supervisor.
Click Service > Workflows > New.
Edit the newly created workflow to include entry, exit, and intermediate steps and save the information.
Create a new SLA by navigating to Service > SLA > New. Or, you can modify the existing SLA and add the newly created workflow.
Before requests can be processed using SLM, a Supervisor typically needs to perform the following sequence of configuration steps:
Define Technicians. Set Roles & Process permissions (Users > Users)
Define service level managers (Users > Users)
To become a service level manager a User must be assigned the Service Level Management Process
Establish business SLAs
a. Specify service level manager
b. Availability %
c. Warning and breach notifications
d. Set priority targets
e. Specify blackout periods
Setup OLAs
a. Specify service level manager
b. Set service targets
Setup Underpinning Contracts (UCs)
a. Specify service level manager
b. Specify Vendor
c. Set service targets
Define Workflows
a. Name the process and associate it with one of the ITIL processes
b. Optionally modify default open and close states { you might need to come back to this once all states have been defined}
c. Specify SLA for the Workflow from Step 3.
d. For each Workflow State, specify:
i. Is the Workflow State active?
ii. Is the State an entry or exit state?
iii. The Contract Type: None / OLA / UC
Specify an OLA if the OLA Contract Type is set.
Select a default Team, that has been assigned the OLA.
Specify a UC, if the UC contract type has been selected.
iv. Should the SLA timer continue counting time when the request has entered this State?
v. Should the State be used to measure SLA restoration or resolution time (for reporting purposes only)
vi. Specify relevant next / previous States to define the end-to-end Workflow.
To prevent the SLA target from being breached, the contract time will be calculated when an OLA or UC is assigned to a State.
e. Update 6b, if required.
Define the Teams
a. Specify Technicians
b. Specify OLAs
c. Specify Workflows
d. Define escalation layers or work groups
Make any modifications to the Workflow State
a. Specify a default Team to provide support for specific States {review 6diii 1a)
After SLAs, Workflows and Teams have been defined, the Service Desk is able to use the system to efficiently process Incident, Problem, RFC and Service Requests according to organizational standards and procedures.
The following steps outline the process of generating and managing an Incident in the system:
Within the Operations > Incident tab select the New button:
a. Assign a Customer
b. Select an Item, which include Services within Service Catalog
c. Profile the request
i. Select a Classification
ii. Enter Description of the request
iii. Complete any custom fields
d. If the proactive analysis option is enabled, proposed solutions will be available within the Analysis Tab. If a relevant Solution is proposed, apply the Solution to close the request. Otherwise, click ‘Next’ to move to the Summary tab of the request screen.
In the Summary Information screen, confirm:
a. SLA
b. Workflow
i. A list of Workflows options is derived based on the SLA selected
ii. If a Workflow has not been assigned to the SLA, then the system default Workflow is assigned to the Incident
c. Team
i. A list of Team options will be derived based on the Workflow selected
ii. If a Team has not been assigned to the Workflow, then the CI’s default Team is assigned to manage the Incident
d. Technician
e. Request Urgency / Impact / Priority
f. Notifications
g. Workflow State (= Status)
h. Add Note(s), and apply private/public visibility and Customer email distribution options
i. Upload attachments
j. Access Audit trail details
k. Access Impact information (i.e., Service Targets, SLA breaches, Item Relationships, Planned Outages, Contract Monitor)
Perform analysis within the Analysis tab
a. Allows the system to recommend a proposed Workaround or Solution
b. Search Workarounds / Solutions
c. Raise new Workaround / Solution
d. Raise a new Problem and link it to the request
e. Raise a new RFC and link it to the request
f. If the request is related to other Incidents, Problems, Change or Service Requests, view all related requests within the Related sidebar in the Summary screen.
Save the request
Group similar or related requests using the Link option and manage the collective from the Group tab or selecting the Group # link in the List View, if this option has been defined for the customized view.