Module 14:

Using System Center Service

Manager

1
Lesson objectives
Introduction to Service Manager Console

How to map the Incident process to Service

Manager

How to map the Problem process to Service

Manager

How to map the Change process to Service

Manager

2
IT-Process vs. tool
All activities and processes leave proof that
the activity or process works as intended
Collect information that gives you data that
supports your KPIs, to show the efficiency
and effectiveness of the process

3
Introductions to the Service
Manager Console

4
Service Manager handing over to
production

5
Stabilizing IT Service management
implementation

Create test cases for tools and process

Create user guides and education material
Test tools and processes
Updates processes, Tools and Organization
to satisfy testing requirements
Consider doing role playing throughout
process scenario

6
After Deploying Service Manager

Conduct User IT training

Conduct Business training and roadshow
Hand over Process ownership to the
Process owners
Conduct first review meeting

7
Incident Mapping to Service
Manager

8
Incident
Define your Requirements matrix
Define Technologies lists
Define Queues for escalations process
Define your resolution times
Define user roles

9
Define Technologies lists
aka Classification Categories
Keep your world simple
People must be able to recognize technologies
Don’t use “Other” if possible
Start simple and go more advanced as time
goes by with your experience
Think about making a public list (user
oriented) and an internal list (IT staff
oriented)

10
Priority Matrix
Understand what urgency is
How quickly should this be solved according to
the business?
Understand what impact is
How critical is it to the business?
How many people are impacted?
Define in phrases what makes a low,
medium, High urgency / impact
It’s low impact when….

11
Priority Matrix

12
Resolution Times
Must be based in SLA / OLA
How long time to register
How long for first line

13
Define Support Groups for
Escalations Process
Can IT-staff be member of multiple teams
Are there clear rules for when and how
escalation to other Support Groups takes
place?

14
Define Area Lists
Are used when you define Manual activities
Can be modified in Library -> Lists view

15
Define Incident Views
Which Teams need Incident views?
What should they see?
What should they be able to do?
Create Incidents?
Modify incidents
Read Incidents?
What should the Incident form look like?
Which parameters should these be filtered
on in the view?

16
Define Incident User Roles
Which User roles will be required?
Will there be different roles for one person?
How should this be accomplished?

17
Incident Notifications
In which cases will users be notified in the
Incident process?

When an incident is updated

When an incident changes category or priority
If an incident has been open for more than x
hours?

18
Incident Activities
Are there any cases where activities should
be pre-defined?

Create scenarios for these and based on this

create the Activity list for the incident type

19
Class Discussion

Incident
Management

20
Problem Mapping to Service
Manager

21
Priority Matrix
Understand what urgency is
How quickly should this be solved according to
the business?
Understand what impact is
How critical is it to the business?
How many people are impacted?
Define in phrases what makes a low,
medium, High urgency / impact
It’s low impact when….
Define how pro-active Problem
Management should work.
22
Define Problem Views
Which views are needed to support the
Problem process?
Group view
Attribute view
Other

23
Define Problem User roles
Will you need more than one group to
handle problems? What are the
requirements to the group(s)?
Are these groups represented as an AD
group in Active Directory?
Are these groups also doing Incident
Management?

24
Problem and Notifications
In which cases will analysts be notified in
the Problem process?

When a Known error is known

When an Activity in completed

25
Change Mapping to Service
Manager

26
Key Change Management Features
Change Request Consists of Multiple Activities
Activity is a Unit of Work tracked in SCSM
Review (“Review Stages”)
Manual (“Work Orders”)
Change Workflows are defined by activities
contained in the Change Templates
Change Request Templates
Emergency, Standard, Minor, Significant, Major
Service Requests/Provisioning
Hire/Fire
Patch Management
…
27
Create & Review Change
Templates
Understand which Change Templates are
needed to support the Change process
If needed an IT-Services mapping to
templates can be used

28
Define Manual Activity for a
Change
aka “Work Order”
Can be assigned to a person or to a group
( “Activity Implementer” )
Contains instructions on how to perform an
activity
Can be marked as Completed or Failed

29
Manual Activity Form

30
Review Activity
“Manual” – people approval needed
Auto-approved (for standard
changes/Service Requests)
Voting logic
Unanimous
Percentage-based
Veto Rule
“Must Vote” Rule (DCR)
“Vote on behalf” – for change coordinators

31
Review Activity Form

32
Change and Configuration Workflow (MOF v4)

33
Process Diagram: mapping to activities

Review/
Color Legend: Group
Approval
Manual Not
Not Applicable
Applicable
34
Translating to SCSM Activities

35
Incident Management Overview
Activity Type

Process (P)

Organization (O)

Tool (T)

Agree on overall process activity steps P

Agree on roles and responsibilities P, O

Configure SCSM to reflect roles T

Define KPI’s and measurements for the process P

Tailor SCSM to reflect reporting requirements T

Receive policy. Who Can submit and how to receive incidents P

Create Source list in SCSM T

Define how Service Monitoring interfaces to incident process P

Tailor SCSM & SCOM to reflect process T

Policy for Incident Record details. Required details in an incident record P

Tailor incident form to reflect policy T

Define Category policy. Define how to sort IT into SW, HW, NW, DB, Process etc. P

Define how to update Categories and interfaces to Change management P

Tailor SCSM to reflect Categories T

Define incident Status policy P

Tailor SCSM to reflect status policy T

Define policy for standard reply when new Incident/service request/RFC has been submitted P 36
Incident Management Overview
Activity Type

Process (P)

Organization (O)

Tool (T)

Define policy for distinguishing between Incident, RFC, Service Request P

Define policy for registering Service request. P
Tailor Service request forms to reflect Service request policy T
Define policy for raising an RFC P
Tailor RFC form to reflect policy for raising RFC T
Define Urgency, Impact and priority policy P
Tailor SCSM to reflect Urgency, Impact, priority policy T
Define procedure for searching existing Incidents P
Tailor SCSM to reflect Searching requirements T
Define Escalation procedure/policy P
Tailor SCSM to reflect Escalation procedure/policy T
Define Notification Policy (who to inform in case of Incidents depending on criticality) P
Tailor SCSM to reflect Notification policy T
Define policy for changing an incident to a problem P
Ensure and tailor link between Incident and Problem and ensure all required information is entered T
and handled

37
Incident Management Overview
Activity Type

Process (P)

Organization (O)

Tool (T)

Define policy for solution description P

Define process for continuous Knowledge management (solution /work around descriptions) P
Tailor SCSM to reflect the required data requirements in solution description policy T
Define interface to change Management process P
Ensure link in SCSM between IM and CM T
Define Escalation procedure/policy P
Tailor SCSM to reflect Escalation procedure/policy T
Define Notification Policy (who to inform in case of Incidents depending on criticality) P
Tailor SCSM to reflect Notification policy T
Define policy for changing an incident to a problem P
Ensure and tailor link between Incident and Problem and ensure all required information is entered and T
handled
Define policy for how to verify a solved incident P
Tailor SCSM to reflect required data and notification requirement when verifying a solved incident T
Define Cause/ Closing codes. What lead to successful incident P

38
Incident Management Overview
Activity Type

Process (P)

Organization (O)

Tool (T)

Tailor SCSM to reflect the required Cause/ closing Codes T

Define closing & solution policy. What are required to change an incident to solved or to closed P
Tailor SCSM to reflect closing / solution policy T
Define incident re-opening policy P
Tailor SCSM to reflect re-opening policy T
Define standard Incident reports P
Tailor SCSM to reflect reporting requirements T

39
Change Management Overview
Activity Type
Process (P)
Organization (O)
Tool (T)
Agree on overall process activity steps P
Agree on roles and responsibilities P, R
Configure SCSM to reflect roles T
Define RFC submission policy. Who Can submit and how to receive RFC’s P
Create Source list in SCSM T
Define procedure for how to fill out an RFC and minimum requirements P
Tailor SCSM to reflect RFC requirements T
Define procedure for standard answer to Change Requestor P
Tailor SCSM to reflect requirements for Standard answer to Change requestor T
Define Policy for Change and RFC status P
Tailor SCSM to reflect requirements for Change/RFC policy T
Define policy for RFC priority (Low, Medium, High, Emergency) P
Tailor SCSM to reflect RFC priority T
Define policy for change category (Emergency, Major, Significant, Minor. P
Tailor SCSM to reflect Change category policy T
Define CAB’s (minor, Significant, major, emergency, unauthorized change) CAB policy P, O
Sign stakeholders (employees, vendors, users, process owners etc) into the various CAB’s in SCSM T, O 40
Change Management Overview
Activity Type
Process (P)
Organization (O)
Tool (T)
Define impact analysis policy (Technical. P
Service management, Financial, Business, Resource management.) to ensure LMG knows how to
assess new RFC’s
Tailor SCSM to reflect the required background details about impact analysis. T
Define standard answer to Change requestor P
Tailor SCSM to reflect standard answer to Change requestor T
Define format and policy for forward schedule of change (FSC) P
Tailor SCSM to reflect requirements for FSC T
Define policy for change owner P, O
Tailor SCSM to reflect the Change owners T
Define interfaces to Release management (build, test, deploy) P
Reflect interfaces and data requirements for Release management I SCSM T
Define requirements for notification policy. Which stakeholders, users and processes should be P, O
informed upon change closure/completion?
Tailor SCSM to reflect Notification policy T, O
Policy for updating CMDB P
41
Change Management Overview
Activity Type
Process (P)
Organization (O)
Tool (T)
Tailor SCSM to reflect data requirement for CMDB update T
Define policy for closing a Change record P
Tailor SCSM to reflect data requirement in relation to Change closure T
Define Policy for Post implementation review (PIR) P, O
Tailor SCSM to include activities and members in PIR T, O
Define KPI’s P
Tailor SCSM to reflect KPI reporting requirements T
Define standard Change reports P
Tailor SCSM to reflect reporting requirements T

42
Using SCSM Review Questions

What are the two things that should be collected

when implementing processes into a tool?

Mention two activities that should be done when

implementing an incident into Service Manager?

Mention two activities that should be done when

implementing change into Service Manager?

43
Hands on Lab

Using Service
Manager

44
Summary and Class Discussion
Understanding how an incident process can
be implemented in Service Manager

Understanding how a problem process can

be implemented in Service Manager

Understanding how a change process can

be implemented in Service Manager

45
 © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not
be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

46