Microsoft System Centre Service Manager Build Document Version: 1.0 Date: 15/10/2012
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Microsoft System Centre Service Manager
Build Document
Version: 1.0
Date: 15/10/2012
Page 2 of 34
Contents Introduction ............................................................................................................................................ 5
References .............................................................................................................................................. 5
1. List of users ................................................................................................................................. 6
1.1. Initial load............................................................................................................................ 6
1.2. Locations ............................................................................................................................. 6
1.3. Departments ....................................................................................................................... 6
1.4. VIP Users ............................................................................................................................. 6
2. Priorities ...................................................................................................................................... 7
2.1. Incidents .............................................................................................................................. 7
2.2. Problems ............................................................................................................................. 8
2.3. Requests .............................................................................................................................. 8
2.4. Changes ............................................................................................................................... 9
2.5. Automated priorities based on categories, users (departments / locations) ..................... 9
3. Categories ................................................................................................................................. 10
3.1. Incidents ............................................................................................................................ 10
3.2. Problems ........................................................................................................................... 10
3.3. Service Requests ............................................................................................................... 10
3.4. Changes ............................................................................................................................. 11
3.5. Knowledge ......................................................................................................................... 12
3.6. Auto-assignment of tickets to groups based on selected category .................................. 12
4. Knowledgebase ......................................................................................................................... 12
4.1. Templates/Style Guide ...................................................................................................... 12
4.2. Status ................................................................................................................................ 12
4.3. Workflow ........................................................................................................................... 13
5. Integrations ............................................................................................................................... 13
5.1. Active Directory................................................................................................................. 13
5.2. SCCM/SCOM ..................................................................................................................... 13
5.3. SharePoint ......................................................................................................................... 13
5.4. Exchange ........................................................................................................................... 13
5.5. SQL Reporting Services ..................................................................................................... 14
6. Reporting................................................................................................................................... 14
6.1. OOTB reports .................................................................................................................... 14
6.2. Data exports ...................................................................................................................... 16
6.3. Scheduling ......................................................................................................................... 16
Page 3 of 34
7. Incident Resolution Codes ........................................................................................................ 16
7.1. OOTB ................................................................................................................................. 16
8. Asset / Configuration Management .......................................................................................... 17
8.1. Initial load of CIs ................................................................................................................ 17
8.2. Dynamic updates from Connectors .................................................................................. 17
8.3. Applications ....................................................................................................................... 17
8.4. Relationships ..................................................................................................................... 18
8.5. Integration with Incident, Request, Problem, Change ...................................................... 18
9. Change Management ................................................................................................................ 20
9.1. Outage Flag ....................................................................................................................... 20
9.2. Implementation Result ..................................................................................................... 20
9.3. Change Statuses ................................................................................................................ 20
10. Workflow ............................................................................................................................... 21
10.1. Queues and Activities ................................................................................................... 21
10.2. Incident ......................................................................................................................... 21
10.3. Problem ......................................................................................................................... 21
10.4. Service Request ............................................................................................................. 21
10.5. Change .......................................................................................................................... 22
11. Surveys .................................................................................................................................. 22
11.1. Transactional ................................................................................................................. 22
11.2. Reporting ....................................................................................................................... 22
12. Auto-ticketing ....................................................................................................................... 22
13. Linking Tickets ....................................................................................................................... 23
13.1. Parent / Child ................................................................................................................ 23
13.2. Ticket types ................................................................................................................... 23
13.1. Managing Child Incident tickets .................................................................................... 24
14. Resolver Groups .................................................................................................................... 25
14.1. Process .......................................................................................................................... 25
15. Mandatory Fields .................................................................................................................. 25
15.1. Incident ......................................................................................................................... 26
15.2. Problem ......................................................................................................................... 26
15.3. Request ......................................................................................................................... 26
15.4. Change .......................................................................................................................... 26
16. Authentication ...................................................................................................................... 26
16.1. Security ......................................................................................................................... 26
Page 4 of 34
16.2. Active Directory Integration .......................................................................................... 27
16.3. Roles .............................................................................................................................. 27
17. Service Level Management ................................................................................................... 29
17.1. Process .......................................................................................................................... 29
17.2. Service Level Metrics: ................................................................................................... 30
17.3. Calendars: ..................................................................................................................... 30
18. Service Catalogue .................................................................................................................. 30
18.1. Service Offerings ........................................................................................................... 31
18.2. Request Offerings.......................................................................................................... 31
19. Self-Service Portal ................................................................................................................. 31
19.1. Design: ........................................................................................................................... 31
19.2. Knowledgebase: ............................................................................................................ 31
19.3. Service Request logging: ............................................................................................... 31
19.4. Incident logging ............................................................................................................. 32
20. Views ..................................................................................................................................... 32
21. Notifications .......................................................................................................................... 33
21.1. Process .......................................................................................................................... 33
22. Maintaining the Tool ............................................................................................................. 34
22.1. Enhancement Process ................................................................................................... 34
22.2. Transport Landscape ..................................................................................................... 34
Page 5 of 34
Introduction This document defines the base configuration of the Microsoft System Center Service Manager tool
to the requirements of <organisation>. The initial build state will be captured: what are the
approved configuration options for productionisation of the Service Manager tool.
Once the build has been completed and signed-off, based on information in this document, the BAU
Enhancement Process will take effect to manage any future configurations.
Unless explicitly stated otherwise, all operations are performed in the Service Manager console with
Administrator privileges.
References
This document should be read in conjunction with, and references these, documents:
Title Description
IT Service Catalogue List of services and functions delivered by <organisation>
SCSM Build Checklist Guiding list of build tasks
Applications List of business and desktop applications, with owners and priorities
Confirmed SR List List of agreed Service Request types to be modelled in Service Manager (serves as an input into Service Requests Build Status document)
SCSM Naming Conventions Defines the format for naming Service Manager elements (e.g. Management Packs, Subscriptions)
Service Manager Maintenance Procedure Defines the process for maintaining the Service Manager environments
Service Manager Build Input Documents:
Change SM Fields Configuration data for Change Management elements
IPR Categories Configuration data for Incident, Problem, Request categories
Notifications Configuration data for notifications (triggers, descriptions, templates, recipients)
Roles Configuration data
Sites List of <organisation> locations
Resolver Groups List of <organisation> resolver groups who will interact with Service Manager
Self-Service Portal Design Conceptual design for SSP portal
Service Requests Build Status Guiding list of build tasks specific to Service Requests (Request Offerings and Templates)
SM Report Requirements List of SM reports
Page 6 of 34
1. List of users
1.1. Initial load
The initial importing of user records into Service Manager is performed using the Active
Directory (AD) connector.
Refer to section 16.2 for more information on the AD connector.
By default all users will be allocated to the role of “End User” through their membership of the
Domain Users AD group.
1.2. Locations
The AD “Office” field is not published in Service Manager by default.
A custom List has been created (location: Library Lists), Location for Offices, which contains
<organisation> locations, and the Incident, Problem, Request and Change forms have been
modified to include this field. Corresponding reports have also been updated to reference the
location field.
1.3. Departments
The AD “Department” field is not published in Service Manager by default. A customisation
would be required if we wanted to report on ticket volumes/metrics by
<organisation>department.
1.4. VIP Users
It is a requirement to be able to easily identify VIP users within Service Manager in order to
manage these users with greater care.
This requirement can be achieved 2 ways:
a) Customising the user tables in the Service Manager database (and subsequently the
corresponding forms) with a VIP flag, that can then be activated for certain users.
Page 7 of 34
b) Using or adding an Active Directory field, that is then referenced within Service Manager
For both options, once the VIP flag has been set, a mechanism is required that provides a visual
notification to the analyst when a VIP user is initially selected and when a ticket is
transferred/updated.
A customisation has been implemented to extend the user table in the Service Manager
database with a VIP flag that can be activated for certain users.
User data is populated automatically through the AD Connector.
Location: Configuration Items Users
Select a user record, and on the Extensions tab, set the isVIP field to True, and then press OK.
By default the isVIP flag is set to Null.
There is no visual notification when a user with the VIP flag set to True is entered as the Affected
User – an email is generated once the ticket is saved to alert the Service Desk that a ticket has
been created for a VIP user.
2. Priorities
2.1. Incidents
The Priority of an Incident is automatically calculated based on the Urgency and Impact selected.
Page 8 of 34
Currently both the Impact and Urgency fields have the same options: Low, Medium, High.
The Impact options are set in the Impact List (location: Library Lists).
The Urgency options are set in the Urgency List (location: Library Lists).
The Priority matrix is configured under Incident Settings, location: Administration Settings
Incident Settings Priority Calculation
2.2. Problems
Similar to Incidents, the Priority of a Problem is set by selecting its Impact and Urgency.
The Problem Priority Matrix is configured under Problem Settings, location: Administration
Settings Problem Settings Priority
2.3. Requests
There is no automatically-calculated Priority number for a Service Request. Urgency and Priority
are set individually based on selecting options.
Page 9 of 34
The Urgency options are set in the Service Request Urgency List (location: Library Lists).
The Priority options are set in the Service Request Priority List (location: Library Lists).
Currently both Priority and Urgency contain the same options: Low, Medium, High, Immediate.
The options can be changed and additional options added, and can be text or integers.
No calculations are performed on the values selected OOTB.
2.4. Changes
There is no automatically-calculated Priority number for a Change. Priority, Impact and Risk are
set individually based on selecting options.
The Priority options are set in the Change Priority List (location: Library Lists).
Current Priority options are: Low, Medium, High, Immediate.
The Impact options are set in the Change Impact List (location: Library Lists).
Current Impact options are: Standard, Significant, Minor, Major
The Risk options are set in the Change Risk List (location: Library Lists).
Current Risk options are: Low, Medium, High, Not Assessed
2.5. Automated priorities based on categories, users (departments / locations)
Applying automatic priorities based on certain parameters is achieved with the use of Queues
and Templates. Once a ticket is created and saved, a Queue can be triggered based on
information contained within the ticket, and a template applied.
For example, Incidents created for users from the Abbotsford site can have an automatic Priority
of 2 applied.
At this stage, no automation will be applied based on Priority of a ticket.
Page 10 of 34
3. Categories
Categories are used to classify tickets and are used for Reporting purposes. Views can also be
created based on ticket categories. The lists will be updated based on information contained in
the corresponding Build Input documents (Change SM Fields and IPR Categories).
3.1. Incidents
Incident categories are set in the Incident Classification List (location: Library Lists).
OOTB values are:
Configuration Data Problems
E-Mail Problems
Enterprise Application Problems
Hardware Problems
Networking Problems
Printing Problems
Software Problems
Other Problems
3.2. Problems
Problem categories are set in the Problem Classification List (location: Library Lists).
OOTB values are:
Application
Database
Document
Facilities
Network
Server
Software
Storage
3.3. Service Requests
Service Request categories are set in the Service Request Area List (location: Library Lists).
OOTB values are:
Content
o Intranet
o Extranet
o Knowledge
o Other
Directory
o Account Management
o OU Management
o Other
Facilities
o Power
o Other
File
o Disk Volumes and DFS
o Shares
o Restore File
o Other
Hardware
o Client
o Server
o Network
o Storage
o Components
o Other
Infrastructure
o Backups
o Monitoring
o Network Connectivity
o Name Resolution
o Proxy or Firewall
o Remote Access
o Server Services
o Telephony
Page 11 of 34
o Other
Messaging
o Client
o Server
o Other
Operations
o Process
o Documentation
o Management
o Other
Security
o Physical
o Information
o Account Management
o Access Control
o Other
Software
o Licenses
o Application
o Operating System
o Patch
o Driver
o Firmware
o Configuration
o Installation
o Other
Other
3.4. Changes
Change categories are set in the Change Area List (location: Library Lists).
OOTB values are: Standard, Minor, Major, Emergency.
Content
o Intranet
o Extranet
o Knowledge
o Other
Directory
o Account Management
o OU Management
o Other
Facilities
o Power
o Other
File
o Disk Volumes and DFS
o Shares
o Restore File
o Other
Hardware
o Client
o Server
o Network
o Storage
o Components
o Other
Infrastructure
o Backups
o Monitoring
o Network Connectivity
o Name Resolution
o Proxy Firewall
o Remote Access
o Server Services
o Telephony
o Other
Messaging
o Client
o Server
o Other
Operations
o Process
o Documentation
o Management
o Other
Security
o Physical
o Information
o Account Management
o Access Control
o Other
Software
o Licenses
Page 12 of 34
o Application
o Operating System
o Patch
o Driver
o Firmware
o Configuration
o Installation
o Other
Other
3.5. Knowledge
Knowledge categories are set in the Knowledge Article Category List (location: Library Lists).
OOTB values are:
Software
Hardware
Printing
Enterprise Application
Networking
Other
3.6. Auto-assignment of tickets to groups based on selected category
The automatic allocation of Incident and Service Request tickets to the relevant resolver group based on
the category selected will involve the creation of a queue and applying a template to alter the Support
Team.
No automated assignments are configured at this stage.
Activities defined within Service Requests and Changes can be allocated to AD Groups, with a notification
sent to the selected Group.
4. Knowledgebase
The knowledge function OOTB with Service Manager is limited in its
functionality.
Information about Knowledge Articles (KA) is viewable in the Self
Service Portal, but the KAs themselves are in Word documents that
need to be opened by the user in order to be viewed.
KAs can be viewed in their entirety within the Service Manager
Console, either by clicking on the link within a ticket or going to the
Knowledge module – location: Library Knowledge
4.1. Templates/Style Guide
Templates can be developed for KA by using the Templates section: Library Templates.
There are no pre-configured KA templates. Templates can be configured for KA categories or
types, e.g. Business Applications.
4.2. Status
Three statuses are available for KAs: Draft, Published and Archived.
Published KAs appear on the Self Service Portal.
Page 13 of 34
Knowledge Articles have Tags which can be set. OOTB Tags are: Incomplete, To Rewrite,
Duplicate.
Custom Views can be created to isolate viewing of KAs based on Status or Tag.
Free text Keywords can be entered for each KA to describe the content and audience of the KA.
These Keywords are used on the Self Service Portal Knowledgebase search facility.
No configuration of Knowledge is being done at this stage.
4.3. Workflow
Workflow cannot be configured OOTB to manage the lifecycle of a KA.
5. Integrations
5.1. Active Directory
The most important Service Manager integration is with Active Directory (AD). AD is used to
display user information and group membership, and is used in defining roles.
Data from AD is also served into the CMDB to present information about users and computers.
5.2. SCCM/SCOM
Data from Microsoft SCCM and SCOM is presented in the CMDB to provide information about
server, printer and desktop infrastructure in the <organisation> environment.
5.3. SharePoint
Microsoft SharePoint Foundation 2010 is used to publish the Self Service Portal, and to access
reports that have been generated using Microsoft SQL Reporting Services.
5.4. Exchange
There is no integration between Service Manager and Microsoft Exchange.
An SMTP server has been defined to allow notifications to be sent from Service Manager to <organisation> users. This is set under Administration Notifications Channels:
We are exploring the implementation of Exchange Connector v3 to enable processing of inbound emails (specifically for approving/rejecting Review Activities). This connector requires Exchange
Page 14 of 34
2010, and as such there is a technical constraint that must be addressed before the connector can be installed.
5.5. SQL Reporting Services
Microsoft SQL Reporting Services is the engine that produces the Service Manager reports. This
has been implemented as a shared service across Service Manager, SCCM and SCOM.
If the OOTB reports require modification, it must be performed in SQL Reporting Services.
6. Reporting
Reporting is a separate module within Service Manager and requires specific
permissions to access.
There are standard OOTB reports that come with Service Manager.
A Data Warehouse is also available that provides access to all the Service Manager
data through the use of cubes. These cubes are configured using SQL Reporting
Services.
We require the ability to report on Incident, Problem, Changes, Requests by site –
to deliver this will require customisation, referencing a custom list of locations.
Refer to the separate register of Reports (SM Report Requirements) required.
6.1. OOTB reports
The format of the OOTB reports in Service Manager cannot be changed within the Service
Manager console – modifications and the creation of new reports must be performed in SQL
Reporting Services. Parameters for the OOTB reports can altered, e.g. the date range, a
specified Priority.
Area Report Description
Activity Management Review Activity Details This report provides detailed information about a specific review activity including the title, description, status, reviewers, approval condition and more.
Activity Distribution This report provides the number of activities as well as several important attributes including status, type, stage, and more. The data can be grouped by Status, Stage, or Type.
List of Activities This report provides a list of activities as well as several of their important attributes including the type of activity, their current status, priority and more.
List of Manual Activities
This report provides a list of manual activities as well as several of their important attributes including their current status, stage, priority, who they are assigned to and more.
Page 15 of 34
Area Report Description
List of Review Activities This report provides a list of review activities as well as several of their important attributes including their current status, stage, approval condition, approval threshold and more.
Manual Activity Details This report provides detailed information about a specific manual activity including the title, description, status, impacted computers and more.
Change Management Change Management KPI Trend
This report provides the number of change requests as well as how many of them are in progress, completed, failed or cancelled. The data can be grouped by Day, Week, Month, Quarter or Year.
Change Request Details This report provides detailed information about a specific change request including the title, description, status, change creator, template and more.
List of Change Requests This report provides a list of change requests as well as several of their important attributes including their current status, category, who they are assigned to and more.
Configuration Management Computer Details This report provides detailed information about a specific computer.
Computer Inventory This report provides a list of computers in inventory.
Configuration Manager Power Activity Report shows Power Activity for the Computers in the organization.
Incident Management Incident Analyst This report provides key metrics regarding a specific analyst's performance including the number of incidents assigned to the analyst, resolved by the analyst, and/or worked on by the analyst as well as any labor logged.
Incident Details This report provides detailed information about a specific incident including the title, description, classification, affected services, affected configuration items, related activities and more.
Incident KPI Trend This report provides the number of incidents, including how many of them are past their target resolution time, how many have been escalated, the average time to resolution, the labor minutes per incident, and the size of the backlog. The data can be grouped by Classification or Category as well as by Day, Week, Month, Quarter or Year.
Incident Resolution This report provides the number of incidents as well as how many of them are past their target resolution time and the average time to resolution. The data can be grouped by Day, Week, Month, Quarter or Year.
List of Incidents This report provides a list of incidents as well as several of their important attributes like who they are assigned to, when they were created, their current status and more.
Problem Management Configuration Items (CIs) with Most Incidents
This report provides a list of configuration items which have a minimum number of associated incidents. It also includes the number of change requests and problems associated with the specific configuration item.
List of Problems This report provides a list of problems as well as
Page 16 of 34
Area Report Description
several of their important attributes.
Problem Details This report provides detailed information about a specific problem.
Service Management Service KPI Trend This report spanning Service Manager/Operations Manager/Configuration Manager enables analyzing key metrics, enabling trending and flexible grouping across services, groups and collections.
Service Summary This report is a scorecard-like report which provides a comprehensive view of the health of a service, including period over period analytic capabilities.
6.2. Data exports
Each of the OOTB reports are run through the Reporting module of Service Manager. The results
can be exported into a variety of formats, including CSV and HTML.
The CSV format will be useful for conducting further manipulation of report data.
6.3. Scheduling
Using SQL Reporting Services and Windows tasks, reports can be scheduled for production and
distribution.
At this stage, no scheduling of reports has been defined.
7. Incident Resolution Codes
7.1. OOTB
A Resolution code is selected with setting the status of an Incident ticket to Resolved.
Resolution codes are used for reporting purposes.
Location: Library Lists Incident Resolution
The following resolution codes have been defined in Service Manager:
Auto Resolved by Problem
Cancelled
Fixed by analyst
Fixed by higher tier support
Resolved by parent incident
Walk through knowledge article
Page 17 of 34
8. Asset / Configuration Management
Carefully consideration needs to be given as to whether or not Service
Manager will deliver the desired functionality for asset and/or configuration
management. OOTB, Service Manager does not provide a true, ITIL-aligned,
CMDB function, and is very much geared towards Microsoft products (being
heavily reliant upon connectors from SCCM and SCOM to populate CI data).
8.1. Initial load of CIs
The following CI categories are pre-defined:
Builds
Business Services
Computers
Environments
Printers
Software
Software Updates
Users
Initially, the Computers, Printers, Software and Users classes will be
populated with data from AD, SCCM and SCOM.
<Organisation> applications will be manually entered as Business
Services.
8.2. Dynamic updates from Connectors
A unique record is created when data is pulled in from AD, SCCM and SCOM connectors. Each
connector is set to refresh on a daily basis, updating information that has changed and adding in
new CIs.
8.3. Applications
<Organisation> Business Applications are configured as
Business Services in Service Manager.
Each Application is allocated a Priority based on the
definition in the IT Service Catalogue. The Priorities are:
Gold – business critical applications supported on a
24x7 basis
Silver – business applications supported on a 12x5 basis
Bronze – unsupported applications (“best effort” only)
Standard SOE – applications that form part of the SOE
Non-Standard – desktop software that is not part of the standard SOE but is available for
deployment (may be subject to additional licensing)
Priorities are configured in the Service Priority List (Location: Lists Service Priority)
Page 18 of 34
For each Application, the following fields
need to be completed:
Display Name – the name of the
application
Classification – select Software
Owned by Organisation – enter
<Organisation>
Priority – select the appropriate
classification
Status – select In Service
Further details, including modelling the Service Components, will be entered as information
becomes available.
Note: The Software class is for directly imported software items from SCCM.
8.4. Relationships
It is possible to relate a configuration
item to other configuration items.
Open an item, select the Related
Items tab and then click the Add…
button to search for related Items
(e.g. computers, software, business
services).
Visual modelling of relationships between configuration items can be achieved in SCOM.
8.5. Integration with Incident, Request, Problem, Change
As far as practical, a CI should be attached to an Incident, Request, Problem or Change, which
serves to deliver valuable information about services, application or infrastructure that is being
regularly impacted.
Page 19 of 34
Incidents
On the General tab there are 2
sections for adding CIs: Affected
Services for Business Services
(applications), and Affected Items
for all other CI types. CIs can also
be attached on the Related Items
tab using Configuration Items:
Computers, Services and People.
Changes
On the General tab the Config
Items To Change section is used
to add affected CIs. CIs can also
be attached on the Related Items
tab using Configuration Items:
Computers, Services and People.
Problem
On the General tab there are 2
sections for adding CIs: Affected
Services for Business Services
(applications), and Affected Items for
all other CI types. CIs can also be
attached on the Related Items tab
using Configuration Items:
Computers, Services and People.
Service Requests
On the Related Items tab there are 2
sections for adding CIs: Affected
Configuration Items and
Configuration Items: Computers,
Services and People.
Page 20 of 34
9. Change Management
9.1. Outage Flag
It is a requirement to be able to easily identify a Change Request that will involve an outage.
This is not native within Service Manager and will require a customisation. The Change Form has
been modified to reference an Outage field:
The List of Change Requests report will be updated to reference this outage flag.
9.2. Implementation Result
The Implementation Result is used to classify the success of a change, and is used for reporting
purposes.
Implementation Result values are set in the Change Implementation Results List (location:
Library Lists).
Current values are:
Successfully Implemented
Implemented With Issues
Partially Implemented
Failed
Rejected
Cancelled
Unauthorised
9.3. Change Statuses
The status of a change is automatically set based on the progress of it’s Activities. The OOTB
statuses are:
New
Submitted
In Progress
On Hold
Completed
Failed
Cancelled
Closed
It is not possible to add additional statuses or modify the existing ones, as the backend automation to set the status may become corrupted, and would require considerable customisation. Therefore the change statuses will remain as is.
10. Workflow
This section defines the workflow to be implemented that performs pre-
defined tasks based on certain criteria. Workflow can include obtaining a
manager’s approval for a software installation, and allocation a New User
account creation request to an appropriate resolver group. Actions are
assigned to users (or groups) through the use of Activities.
10.1. Queues and Activities
Activities describe an action that has to be performed. Activities can be
designed in a linear fashion, or parallel activities can be defined.
Activities are defined within Service Requests and Changes and can be
configured for each request or change type through the use of
templates.
Active Activities are viewable as separate Work Items.
The two most common types of Activities will be Review Activities and Manual Activities:
Review Activities solicit approval to do something
Manual Activities require the assignee to perform an action (usually after a Review
Activity)
Queues can be used to simulate workflow for Incidents and Problems (which don’t have the
capability to use Activities). Queues are triggered upon the creation or updating of a Work Item,
and can update values of a ticket (for example Priority), or assign it to a particular resolver group
based on its category.
10.2. Incident
There will be no workflow for incidents. Each incident ticket will be manually assigned to a
resolver group.
10.3. Problem
There will be no workflow for problems.
10.4. Service Request
The process for creating workflow for Service Requests involves several iterative steps:
Identify new Service Request type
Create the Template
Create the Request Offering
Attach to a Service Offering
Define Approval Activity
Define Manual Activity (or Activities)
Configure Notifications
Test
Page 22 of 34
A common Activity for Service Requests will be soliciting approvals from the requestor’s manager,
which relies on the Manager field in Active Directory being correctly assigned:
A Notification must be configured for each Activity item, otherwise the assignee of an Activity will
not be aware that they have to action something.
10.5. Change
Workflow is required for Change tickets to effectively manage the change lifecycle, from initiation
to approval to implementation.
Workflow will be defined based on certain change categories and types.
Similar to Service Requests, the use of Activities will control the change lifecycle, and needs to be
defined in each change template.
11. Surveys
We have a requirement to send surveys to end users to gauge their satisfaction with the level of
service provided by IT.
Service Manager does not have any survey capabilities, so another solution has to be defined.
11.1. Transactional
Transactional surveys are sent to the Affected User upon resolution of a ticket.
Users should not be surveyed more than once every 60 days.
The survey must contain details of the ticket the user is being surveyed about.
11.2. Reporting
Results of the survey must be available for analysis, as they are a key input into continual
improvement.
12. Auto-ticketing
Auto-ticketing is the automatic creation of incident or request tickets in Service Manager from
external events. For example, SCOM generates an alert for low disk space on a server, and an incident
ticket is generated and assigned to the Windows team for investigation.
No auto-ticketing will be configured initially.
Page 23 of 34
13. Linking Tickets
13.1. Parent / Child
There are various options available for linking tickets to each other, either through explicit
Parent/Child menu items or through the Related Items section of a ticket.
13.2. Ticket types
Incidents
There are explicit options for linking Parent and Child incident tickets. From within an Incident
ticket, select either Link or Unlink to Parent, or Link to New Parent Incident. You are able to select
any Incident ticket as a Parent.
You can also create other ticket types (Problem, Change Request, Service Request) from within an
Incident ticket, and the incident details will be copied over to the new ticket.
Problems
From within a Problem ticket you can create Change Requests and Release Records, and the
Problem details will be copied over to the new ticket.
You can relate Problem tickets to other Problems, and to Incidents, Service Requests and
Changes using the Related Items section and searching for the desired ticket:
Page 24 of 34
Service Requests
You can relate Service Request tickets
to other Service Requests, and to
Incidents, Problems and Changes
using the Related Items section and
searching for the desired ticket under
Work Items:
Changes
From within a Change ticket, selecting Create Change Request will create a related Change ticket,
with the new change referencing the existing Change Request in the Related Items section.
You can also relate Change tickets to other Changes, and to Incidents, Problems and Service
Requests using the Related Items section and searching for the desired ticket:
13.1. Managing Child Incident tickets
Incidents tickets have specific options that can be set that govern the treatment of tickets that
have a parent/child relationship defined.
Location: Administration Settings Incident Settings
Setting Available Options Business Requirement
Resolving Child tickets Do not resolve when Parent is resolved
Automatically resolve when Parent is resolved
Let Analyst decide when Parent is resolved
Let Analyst decide when Parent is resolved
Child ticket resolution category
Same as Parent
Choose a category
Choose a category: Resolved by parent incident
Page 25 of 34
Setting Available Options Business Requirement
Auto reactivation of child tickets
Do not reactivate Child when Parent is reactivated
Automatically reactive Children when Parent is reactivated
Let the Analyst decide
Do not reactivate Child when Parent is reactivated
Status of active child tickets
Do not change the status
Automatically change the status of active children when linked to a Parent
Do not change the status
There are no settings available for managing related Request, Change or Problem.
14. Resolver Groups
The Resolver Groups are the <organisation> (and potentially external) functional teams will action or
be involved with Incidents and Requests. (Problems and Changes do not have a Resolver Group field
natively in Service Manager.)
14.1. Process
a) Determine Resolver Groups
b) Define the corresponding AD Groups (and allocate users)
c) Define Groups in Service Manager as Support teams – Lists are Incident Tier Queue, Service
Request Support Group (location: Library Lists)
d) Adjust / Define Roles in Service Manager
e) Assign AD Groups to Service Manager Roles
f) Setup Notifications for each group for both Incidents and Requests (and Activities)
Refer to the separate input documents for Resolver Groups and Security Roles.
15. Mandatory Fields
This section describes the OOTB fields on the Work Item forms that require input or selection, and
outlines additional fields required to be set to Mandatory.
Page 26 of 34
Setting additional fields as Mandatory is a customisation will be require use of the Service Manager
Authoring Tool to manipulate the required forms.
15.1. Incident
Current mandatory fields:
Title
Classification category
Impact
Urgency
Recommend setting the Affected user field as mandatory.
15.2. Problem
Current mandatory fields:
Title
Category
Impact
Urgency
Recommend setting the Affected user field as mandatory.
15.3. Request
Current mandatory fields:
Title
Urgency
Priority
Recommend setting the Affected user field as mandatory.
15.4. Change
No mandatory fields have been defined.
To be defined in conjunction with the Change Manager.
16. Authentication
16.1. Security
Only Service Manager Administrators are able to configure user roles and permissions from within
Service Manager. Access to Service Manager will be through the use of Active Directory (AD)
groups; each Service Manager Role will have a corresponding AD group. Group membership is
controlled by people who have access to modify AD group permissions.
Page 27 of 34
16.2. Active Directory Integration
User information is populated using a Connector into Active Directory. The Connector is
configured under Administration Connectors.
The Connector and Active Directory are maintained by the <Organisation> IT Windows team.
The AD Connector query needs to include Groups as well as Users. The Groups need to be
viewable within Service Manager to enable notifications to support teams to work.
16.3. Roles
The following roles are defined OOTB within Service Manager. By default all users are allocated to
the End User role, and can be upgraded manually to other roles based on their specific
requirements.
Groups will be defined in Active Directory (AD) in alignment with the <Organisation> Operating
Model, and then populated with users. These AD groups will then be allocated to Roles.
Refer to the separate Roles Matrix for a definition of which <Organisation> User Types will be
allocated to which Service Manager Roles.
As far as practically, the OOTB Roles will be used.
TITLE DESCRIPTION AD GROUP
Activity Implementers
Activity Implementers can edit only manual activities that are in their queue scope. They have read-only access to other work items that are in their queue scope and to configuration items that are in their group scope.
Administrators Administrators have full access to all operations. Similarly, their queue scope and their group scope contain all objects in the system.
This role must contain one or more global groups.
Page 28 of 34
TITLE DESCRIPTION AD GROUP
Advanced Operators
Advanced Operators can create or edit any work items that are in their queue scope and any configuration items that are in their group scope. They can also create, edit, and delete the announcements that are displayed on the Service Manager Self-Service portal.
Authors Authors can create or edit any work items that are in their queue scope and any configuration items that are in their group scope. They may also create, edit, and delete announcements that are displayed on the Service Manager Self-Service portal. Authors can also make limited customizations that are stored in management packs. Such customizations can include creating, editing, and deleting list items, tasks, templates, views, and view folders.
Change Initiators
Change Initiators can create new change requests and activities for configuration items that are in their assigned group scope. Change Initiators also have read-only access to other work items such as incidents, change requests, or problems that are in their assigned queue scope.
Change Managers
Change Managers can create and edit change requests and activity work items (such as review activities and manual activities) that are in their queue scope. Change Managers also have read-only access to other work items that are in their queue scope and to configuration items that are in their group scope.
End Users End Users can use the self-service portal to create incidents, request software installation, view announcements, and search the knowledge base.
Incident Resolvers
Incident Resolvers can edit and create incidents, problems, and manual activities that are in their queue scope. Incident Resolvers also have read-only access to other work items such as change requests that are in their queue scope and to configuration items that are in their group scope.
Problem Analysts
Problem Analysts can edit and create problems that are in their assigned queue scope. Problem Analysts also have read-only access to other work items such as change requests or incidents that are in their queue scope and to configuration items that are in their group scope.
Read-Only Operators
Read-Only Operators have read-only access to work items in their queue scope and to configuration items that are in their group scope.
Page 29 of 34
TITLE DESCRIPTION AD GROUP
Release Managers
Release Managers can create and edit release records and activity work items (such as review activities and manual activities) that are in their queue scope. Release Managers also have read-only access to other work items that are in their queue scope and to configuration items that are in their group scope.
Service Request Analysts
Service Request Analyst can create and edit service requests and activity work items (such as review activities and manual activities) that are in their queue scope. Service Request Analysts also have read-only access to other work items that are in their queue scope and to configuration items that are in their group scope.
Workflows User roles that are based on the Workflow profile can create and edit any configuration item or work item.
Process Roles are defined and maintained in Administration Security User Roles.
a) To add an AD User and Group account to a Role, open the Role, select Users, click Add:
b) and then select the desired account from the subsequent dialog box and click OK.
17. Service Level Management
17.1. Process
a) Create / Verify Calendar
b) Create Queue
c) Create SLO
d) Create Notification Subscriptions
e) Adjust Reports
Page 30 of 34
17.2. Service Level Metrics:
Type Target Resolution Warning
Priority 1 Incident 2 hours 1 hour
Priority 2 Incident 4 hours 2 hours
Priority 3 Incident 8 hours / 1 day 3 hours
Service Request 3 days 1 day
Resolution Warning notifications are calculated as the time before a breach (working backward
from the Target time.
17.3. Calendars:
Calendars are applied to Service Level Objectives. We can have one or more calendars to reflect
the different operating models of IT. Location: Administration
Service Level Management Calendar
For each Calendar, the Time zone, Working days and hours need to
defined, along with the Holidays that specify the dates to exclude:
18. Service Catalogue
The Service Catalogue consists of Service Offerings and Request Offerings, and is where we define our
Service Requests. Location: Library Service Catalog
Defining a Service Request in Service Manager
Syst
em
Ad
min
istr
ato
r
Build
Identify new Service Request
type
Create the Template
Create the Request Offering
Attach to a Service Offering
Define Approval Activity
Define Manual
Activity (or Activities)
Configure Notifications
TestConfigure Queues
Configure SLO
Page 31 of 34
18.1. Service Offerings
Service Offerings are a collection of Request Offerings, and should be defined first. When defining
Service Offerings, the Language should be set to Null.
18.2. Request Offerings
Request Offerings must be attached to a Service Offering and their status set to Published in
order to appear on the Self-Service Portal.
Prepare a corresponding template first before creating the Request Offering.
Both Service Offerings and Request Offerings should be stored in a custom Management pack.
Refer to the Service Request input document for a list of Service Requests to be created.
19. Self-Service Portal
The Self-Service Portal (SSP) is the primary interface for end users into Service Manager, and by extension, IT,
therefore it is vitally important that the information presented and the functions available on it are
informative, intuitive and easy to access.
The functions available to users of the SSP are:
Information – there is limited space for information to be displayed to users, for example
how to contact the Service Desk, links to other IT resources, etc.
Knowledgebase Articles – referred to as Help Articles on the SSP, there is a search function
and Knowledge Articles are also viewable when completing a request (if they have been
attached to a Request Offering)
Creating Service Requests and Incidents – tickets can be created by users to request
something or report an issue
Viewing historical Service Requests and Incidents – users can see a history of the tickets they have
logged (both directly on the SSP and also with the Service Desk), and can check the status
Activities – Review activities can be completed on the SSP, for example a manager will access the SSP
to approve a software installation request from one of their employees.
19.1. Design:
Refer to the separate Self-Service Portal design document for information on the design of the SSP.
19.2. Knowledgebase:
Every Knowledgebase Article with the status of “Published” will be accessible by users in SSP. A
customisation to the design of the SSP has been made to hide the Knowledgebase menu item
from view. Articles attached to the Request Offerings are still viewable.
19.3. Service Request logging:
Service Requests on the SSP take the form of Request Offerings, which are grouped into Service
Offerings.
Page 32 of 34
Examples of Service Offerings are “End User Requests” and “Software”, and are displayed on the
SSP homepage:
Available Request Offerings under the “End User Requests” Service Offering are:
Each of these Request Offerings need to be defined under the Service Catalog section in the
Service Manager console (location: Library Service Catalog Request Offerings
Request Offerings must have the status of “Published”, and be associated with one or more
Service Offerings in order to be displayed on the SSP.
19.4. Incident logging
If users wish to report an Incident (as distinct from a
Service Request), the Generic Incident form is used. This form will capture the issue details and
will be qualified by the Service Desk who will then determine what steps need to be taken.
The Generic Incident form is accessible on the SSP homepage (“Create a request”).
20. Views
Each resolver group should have a view that restricts the list of tickets displayed to their own group.
Views are created and maintained under each area under Work Items.
Page 33 of 34
21. Notifications Notifications are sent to provide information about the status of a ticket.
Notifications in Service Manager are sent using email (other notification methods,
such as SMS, require the implementation of 3rd party connectors).
Notifications involve the use of Templates which define the content of the email
message.
Notifications can be configured either using the Notifications section or the
Workflows section, both available under Administration.
Workflow should be used for basic notification types – you are limited to
selecting certain fields as recipients of the email
Notifications can be used for more complex notification types
21.1. Process
a) Define Email Template – a template is required for each notification type (see table
below).
b) Define Queue or use Workflow
c) Define Subscription (if using Notifications)
Refer to the separate document detailing Notifications to be implemented in the tool.
Page 34 of 34
22. Maintaining the Tool
Once the Service Manager tool has been built according to the configuration in this document, future
configuration / maintenance will be governed by the BAU Change Management process.
Refer to the separate Service Manager Maintenance Procedure for detailed information on the BAU
maintenance process.
22.1. Enhancement Process
All proposed modifications to the tool will be captured and assessed using the defined
Enhancement Process. Enhancements that are approved will be developed and implemented
according to the Change Management process.
22.2. Transport Landscape
As part of the Change Management process, each approved enhancement will be applied to the
Service Manager Development Environment first, and then assessed for technical assurance.
Once verified as stable, each enhancement will then be progressed to Production, again following
the Change Management process.
Service Manager DEV Service Manager PROD
RFCEnhancement Request
RFC
As far as technically practical, all changes will be implemented in the DEV environment in a
Management Pack. Once verified as successfully, the Management Pack will be copied from DEV
to the PROD environment, and further testing conducted.
Related Documents
