This chapter aims to provide a background into the creation of processes aligned with ITIL and Microsoft Operations Framework (MOF) principles and explains some of the key areas and how they relate to Service Manager; specifically, we will cover the following areas:
Understanding ITSM frameworks
ITIL© processes
Creating an Asset Management process
Creating a Configuration Management System (CMS) process
Creating a Service Request Fulfilment process
Creating an Incident and Problem Management process
Creating a Change and Release Management process
Creating an IT Service Desk
The Service Level Management process
Dependencies and relationships between ITSM processes
System Center 2016 Service Manager (SCSM) is built on the principles of the Information Technology Infrastructure Library (ITIL©) and the operational principles of the Microsoft Operations Framework (MOF). This chapter discusses the operational execution of these principles in real-world implementations.
There are various books and online resources available to you on ITIL© and MOF. The authors recommend you review and research the principles of ITIL© and MOF in the areas in the scope of your SCSM implementation.
The goal of creating processes, regardless of the framework, is to move your organization or teams from using individual flexible approaches to using an agreed uniform policy-driven best practice approach to meet your objectives. This approach is usually described as process maturity.
ITIL© is commonly described as an industry-recognized process framework. MOF is the Microsoft standard for the execution of the processes typically using (but not limited to) Microsoft products.
This recipe provides a summary analysis of the IT Service Management (ITSM) frameworks in general and what they mean to each organization.
A general understanding of the objectives of standards and frameworks is required for this recipe.
Plan to invest in one or more of the following:
Buy this book
Research the subject of frameworks using your preferred method of learning
Attend an accredited training course in the subject
Adopt and adapt frameworks to your specific organization needs, strategies, and capabilities
IT Service Management is a broad term used to describe a process-focused approach to IT management. The goal for most organizations is to implement a service-focused approach to delivering IT dependent services to the end customer.
The industry standard approach for achieving the ITSM objective is to use best-in-class standards as a guide. Examples of common industry frameworks include, but are not limited to, the following:
Information Technology Infrastructure Library (ITIL©)
Microsoft Operations Framework (MOF)
Core Practices
Frameworks are guides and can be compared to the rules of a game (for example, soccer). In a game, the rules provide a consistent approach but do not limit the individual or team strategy. Another critical factor is individual creativity, which, when championed, often leads to a strategic advantage.
ITSM frameworks work best for organizations when the adoption is personalized to the organizations specific strategies and internal capabilities.
This recipe provides a summary discussion of the current ITIL© V3 processes.
Plan to do one or more of the following:
Attend one or more ITIL© training courses in the recommended order
Invest in the ITIL© official book(s) and complementary books
Use the vast free resources on the Internet
Implement and improve your organizational ITSM processes using the ITIL© knowledge as a guide
Review and update your processes in line with organization strategies and capabilities
ITIL© processes take a repeatable cyclic approach to ITSM organization underpinned by continual service improvements. The ITIL© goals are aimed at ensuring the following for the organization:
Plans for services
Catalogues and tracks IT services
Introduces new services with minimal risks
Manages and operates active services consistently
Performs maintenance and updates to existing services with minimum risk and maximum value to the business
Continually monitors and improves the services delivered to the business
The official phases of ITIL© are as follows:
Service Strategy
Service Design
Service Transition
Service Operation
Continual Service Improvement
SCSM is a technology capability enabler of a subset of the ITIL© processes. It is important to follow the principle of People, Processes, and Products. SCSM is a product that complements your organizations agreed processes and needs people to implement, manage, and continually improve the overall IT service strategy.
ITIL© implementation is not mandatory for SCSM deployment, but an understanding of ITIL© is recommended.
Appendix B, Useful Websites and Community Resources provides a list of useful websites for ITIL© and is highly recommended by the authors.
This recipe will provide steps for creating a sample Asset Management process.
For this recipe, the authors recommend you read up on the difference between asset inventory and asset management as an organizational process.
Asset Management is a life cycle process, which tracks an IT asset with its associated financial data from when the asset is requested to when the asset is retired, as shown in the following figure:
;
An example of the steps for creating an Asset Management process is as follows:
Agree and document the organization's asset management policy.
Document the operational process to support the asset management policy.
Create and assign people roles to manage the process. At a minimum, you should plan to include the following:
Hardware Asset Managers
Hardware Asset Inventory agents
Software Asset Managers
Software Asset Inventory agents
Identify and agree on an asset register management system. An asset register in its basic form is a manual process. In advanced scenarios, you may be able to automate this process with a tool such as a bar-code scanner. It should capture the following:
Capture the IT asset type
Capture financial information
Align the IT asset to its financial data
Capture the input to a Configuration Management system (CMS)
Continually aligned to the CMS
Implement Asset Management in SCSM using one of the following methods:
Manually extend the Configuration Items (CI) class to include financial data for assets
Purchase an asset management solution for SCSM (for example, Provance IT Asset Management Pack for SCSM or Cireson Asset Management)
Continually review the policy and operational process. The goal of this step is to improve the process and ensure compliance.
Asset Management begins and ends with people and ultimately can cost or add value to a business. A non-IT related analogy is the lessons from retail stock takes, which typically happen annually. The stock take is the best opportunity for a retail shop to get the most accurate figure for its profit or loss on stock. Two forms of lost revenues are as follows:
Damaged goods
Missing goods
IT asset management is the stock take required for all your technological assets, and its resultant analysis for intelligent decision making to provide factual compliance measurements. The IT equivalent of the stock take process is referred to as audits for software and hardware. SCSM with partner extensions or in-house authoring provides 80 % of the Asset Management for the organization. People and process critically account for the high value of 20 percent.
There are various tools (products) labeled as Asset Management tools. The true Asset Management tools should have the capability of tracking assets from order to decommissioning, and in some cases, recommissioning.
Asset Management is an end-to-end process, and the tools are enablers of successful implementation. Successful Asset Management organization programs recognize the full life cycle management of assets.
See the Using the SCSM Authoring Tool and Extending Service Manager classes recipes in Chapter 11, Extending SCSM with Advanced Personalization, for advanced recipes on management pack authoring.
This recipe provides steps for creating a Configuration Management System process.
This recipe is focused on a Configuration Management System (CMS) process using SCSM. The CMS process differs from a Configuration Management Database (CMDB). A CMS combines one or more CMDBs. SCSM implements a CMS within its CMDB by merging data from multiple CMDBs including the following:
Active directory (AD)
System Center Configuration Manager (ConfigMgr)
System Center Operations Manager (OpsMgr)
This recipe is focused on how you create a CMS process with SCSM using AD, ConfigMgr, and OpsMgr.
An example of the steps for creating a CMS process is as follows:
Plan to agree and document the organization configuration management policy.
Document the operational process to support the configuration management policy.
Create and assign people roles to manage the process.
Install and configure the CMDB systems in scope (in this example, AD, ConfigMgr, and OpsMgr).
Add the AD capable assets to the AD CMDB.
Discover the AD joined assets with ConfigMgr and deploy the ConfigMgr agent.
Discover the AD joined assets with OpsMgr and deploy the OpsMgr agent.
Configure the AD connector for SCSM and synchronize the data from AD with SCSM.
Configure the ConfigMgr connector and synchronize the data from ConfigMgr with SCSM.
Configure the OpsMgr connector and synchronize the data from OpsMgr with SCSM.
The CMS example structure is shown in the following figure:
SCSM addresses the technology requirements of a CMS process by providing a simplified and consistent framework for connecting multiple CMDBs. In the example, the three CMDBs provide information, which SCSM merges to provide a single view of the asset. Using a database server as our asset, here's an example:
AD provides the computer details and information registered in the AD CMDB
ConfigMgr provides information on the hardware and software of the asset (for example, 64-bit operating system with Microsoft SQL Server 2014)
OpsMgr provides information on what databases are installed on the computer
SCSM presents a consolidated view of this information to the analyst and is dynamically refreshed by the owner of the data.
SCSM builds the ITIL© process on its CMDB, which is a dynamic CMS. The CMS approach ensures that the data accuracy and management is performed at the source (AD, ConfigMgr, OpsMgr, or another supported connector). This approach removes the risk of data inconsistency typical of other systems where the IT Service Management (ITSM) tool does not automatically synchronize with CMDBs in scope.
The Importing Active Directory configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)
The Importing Configuration Manager configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)
The Importing Operations Manager configuration items recipe in Chapter 4, Building the Configuration Management Database (CMDB)
This recipe provides guidance on creating an organization Service Request Fulfillment process.
Service Request Fulfillment is typically a process put in place to support a proactive approach to providing services to customers.
An example of the steps for creating a Service Request Fulfillment process is as follows:
Agree and document the organization Service Request Fulfillment policy.
Document the operational process to support the Service Request Fulfillment policy.
Create and assign people roles to manage the process.
Create a service catalog of the organization services available to the end customers.
Sort the services by categories. Here are two examples of category types:
Approval required services
Non-approval required services (standard services)
Agree and establish the organization-supported channels for requesting services. Examples of channels include the following:
Phone calls into the service desk
E-mail
Self-service Web Portal
Publish the list of services and provide guidance on how to order services, including approval processes and costs.
Provide training and guidance to the support teams responsible for Service Request Fulfillment.
Plan to review the process and improve the service based on customer feedback and technological advances. An example of a Service Request Fulfillment process structure is shown in the following figure:
A Service Request Fulfillment process aims to address the proactive goals of ITSM. Some of the common objectives when establishing this process are as follows:
Provide predictable services at a known cost.
Engage customers by using predictable published channels of service delivery.
Improve the change management processes. A repeatable change request with a low risk known outcome may qualify for a published Service Request with a simpler approval process.
Provide visibility and proactive management of services in the service catalog.
Service Requests are typically requests for services that do not require change management, but may or may not require approval. As an example, we can have a process for requesting access to a special printer or a request for premium software.
This recipe discusses creating an Incident and Problem Management process.
In Incident Management, we focus on restoring a service to its known mode of operation before an unplanned interruption. Problem Management requires you to focus on understanding the actual cause of the interruption with the goal of providing a permanent resolution.
The ITIL© framework books and online resources discuss best practices for Incident and Problem Management processes. You must plan to review and understand Incident and Problem Management principles as a prerequisite to creating the processes.
An example of the steps for creating an Incident and Problem Management process is as follows.
Here are the example steps specific to an Incident Management process:
Agree and document the organization Incident Management policy.
Document the operational process to support the Incident Management policy. This should include but not be limited to the following:
Support hours
Classification categories
Escalation procedures
Create and assign people roles to manage the process, for example, Service Desk analysts:
Desktop support
Infrastructure analyst
Service Desk managers
We typically have two channels for Incident Management:
Service Desk team-created incidents (using the SCSM console Sample process steps from incident creation to priority allocation) are shown in the following figure:
Automated or end user self-service created incidents (end user web portal, e-mail, or automatic system event driven). Sample process steps from incident creation to priority allocation are shown in the following figure:
The difference between the two typical channels is how the incident is initially categorized (triage). The next step, Process Incident, involves the creation of a process flow to match how the Incident Management team manage the incident based on your policies and procedures. An example is shown in the following figure:
Monitor and report on the performance of the Incident Management process. The aim is to improve the process, and also identify incidents that require Problem Management.
Here are the example steps specific to a Problem Management process:
Agree and document the organization Problem Management policy.
Document the operational process to support the Problem Management policy.
Create and assign people roles to manage the process, for example:
Problem analysts
Problem managers
Review the Incident Management process with the aim of identifying instances of the following type:
Repeated issues over a defined period (for example, monthly, quarterly, or annually)
Incidents with known workarounds (typically implies there is an opportunity for root cause investigation)
Perform detailed investigation on incidents escalated to Problem Management using internal experts or third-party external support.
Create a change request for problems with known permanent fixes.
Incident Management is about getting services that people rely on back to an agreed operational state as soon as possible. An example of Incident Management is a customer who is unable to access their documents:
On investigation, we find that the issue is with the laptop assigned to the customer.
We issue the customer with a loan laptop and confirm access to their document.
The previous steps will resolve the incident, but we still have a problem. What is wrong with the customer's laptop?
The answer to the question is Problem Management. We use Problem Management to identify the true (root) cause of the issue. We can continue with our scenario from Incident Management:
The desktop engineering team identifies the issue as a network hardware device failure in the laptop.
The team also identifies that this issue has been happening to a number of laptops over the last quarter.
The team also identifies through asset management that we purchased a set of laptops from a vendor and all the issues relate to this set.
We escalate to the vendor and get a driver fix.
A change request is raised to proactively apply the fix to all laptops from the set.
The fix applied to all laptops in scope resolves the issue on the original laptop. We can close the problem, and also change the original status of the incident to closed. A final best practice will be to create a knowledge article about this known issue and its corresponding fix.
The previous examples illustrate how Incident Management and Problem Management work in practice.
This recipe discusses creating a Change and Release Management process for an organization.
In Change Management, we focus on enhancing existing services, service components, or introducing new services and components without an unplanned interruption to existing services. Release Management focuses on when the changes are implemented and manages planned interruption to services.
The ITIL© framework online resources delve much deeper into the best practices for the Change and Release Management processes. You must plan to review and understand Change and Release Management principles as a prerequisite to creating the processes.
An example of the steps for creating a Change and Release Management process is as follows:
Agree and document the organization Change and Release Management policy with the aim of identifying the following:
Change types and categories
Change type priorities
Policy owner
Create and continually update a service map for all services and applications in scope of Change and Release Management. Examples include but are not limited to the following types of service: infrastructure services, messaging services, and collaboration services. A best practice industry approach is the RACI model:
Responsible (R): Who is responsible for the service or service component?
Accountable (A): Who is accountable for the service? This is typically the assigned business unit application owner.
Consulted (C): Who is consulted about the service operations? Typically, this is a support team acting as the subject matter experts.
Informed (I): Who is informed about service availability?
Document the operational process to support the Change and Release Management policy. The operational procedures should include the following:
Technical approvers and management approvers
Plan for proxy approvers to cover expected or non-expected absence of main approvers
Maintenance schedules (approved change implementation windows)
Release process structure:
By change stage
By change type
By maintenance window
Create and assign people roles to manage the process, for example:
Change managers
Release managers
Change implementers (this would be a logical role as implementers will vary based on the change type and related service)
Review the Change and Release Management process with the aim of identifying instances of the following type:
Candidates for Service Request fulfillment (changes that have been successfully validated as low risk and low impact based on an agreed number of successful implementation results).
Changes requiring re-classification, for example, a minor change that results in a major outage due to an identified dependency service.
Release window adjustment due to a business process schedule change, for example, a financial audit application used during peak accounting periods may require a special release window.
The Change and Release Management process, once established, typically has the following operational states:
Initiate
Approve:
Technical (validation from a technical perspective)
Management (validation from a cost and business risk perspective)
Implement and release:
Implementation steps and owners (who does it and how)
Release schedule alignment (when it gets done)
Post implementation review, for example:
Successful in the time allocated
Successful but overrun time allocated
Failed
Resubmission
The following figure provides an example of the process from the change initiation stage:
In Change Management, we use Release Management principles to coordinate multiple changes in cases where these changes may impact on each other. We focus on the following areas when creating and implementing Change Management:
Organization culture:
Successful Change Management creation requires complete buy-in from the whole organization
Exceptions and breaches of Change Management are opportunities to educate and refine the process as appropriate
Change Management is a journey, not a destination (expect changing conditions and adapt as appropriate)
Categorization and classification:
What type of change, and how does it impact existing services?
How important is the change?
Approvals:
Who has the authority to approve?
Who has the best knowledge on the impact and risk to the existing services?
Cost justification
Post implementation analysis:
Unplanned impact of changes
Configuration management updates and service catalogue maintenance
Lessons learned (Knowledge Management)
Release Management can be as follows:
Simple: Manage the forward change schedule
Multiple changes that affect the same service component requires coordination
Multiple changes grouped and released during the same maintenance window
Complex:
Extension of application life cycle management.
New software developed in house.
Patch Management is a candidate for Release Management.
Release Management is a discipline with broad and wide coverage. A best practice for creating the process is this: you should plan to assign a Release Management expert. The process should also have a supported agreed organizational policy.
This section provides an example of what is typically required to create an IT Service Desk.
Service Desks are organization-specific but share a common goal. The goal of most Service Desks is to be the central point of contact for customers in the following areas:
Request for services
Unplanned outages or interruptions to services
Feedback channels for improvement to existing services
Coordination and tracking of active requests and incidents
A prerequisite for creating a Service Desk process is to define what role it would play in the overall ITSM strategy.
Service Desks principles are defined in the ITIL© Service Operations books. Plan to review the industry best practices before creating an organization-specific version.
There are three main types of Service Desk:
Local Service Desk: A Service desk in each customer's geographic location, independently managing support services
Central Service Desk: One service desk that supports all geographic locations and offers a consolidated picture of issues and requests across the organization
Virtual Service Desk: Use technology to manage either of the first two types from any location
The successful Service Desk process is based on communication and coordination. Here are some categories of tools you must plan to implement to support the process:
Integrated Service Management and Operations Management systems (for example, the Microsoft System Center Management product)
Advanced telephony systems (for example, auto-routing, hunt groups, Computer Telephony Integration (CTI), Voice Over Internet Protocol (VOIP))
Interactive Voice Response (IVR) systems
Electronic communication (voice, video, mobile, intranet, Internet, and e-mail systems)
Knowledge, search, and diagnostic tools
Automated operations and Network Management tools
Here are the common functions the Service Desk should aim to perform:
Receive calls and act as the first-line customer liaison
Record and track incidents and complaints
Keep customers informed about request status and progress
Make an initial assessment of requests, attempt to resolve them, or escalate as appropriate
Manage the request and issues life cycle, including closure and verification
Communicate planned changes and disruption to services
Coordinate hierarchical and functional escalations
Highlight customer and service desk personnel training opportunities
Monitor and track Service Level Agreements (SLAs) and Operational Level Agreements (OLAs)
Report on customer trends and service desk performance
The service desk process, once established, should deliver the following:
Act to lower the total cost of IT ownership
Support the integration and management of the service portfolio and catalogue
Make efficient use of resources and technology
Optimize investments and the management of business support services
A service desk should aim to provide a unified and simplified experience to the customers it serves.
Service Level Management (SLM) is the foundation and underpinning element of ITSM. This recipe looks at the common input components of SLM and the deliverables of the process. SLM typically can be applied internally, externally, or both. The external application of SLM can be complex as it typically requires legal contracts with external providers outside an organization. In this recipe, our focus will be on the internal execution of SLM.
SLM is a vital organization function. The goal of SLM is to ensure that the customers' expectations are met in line with formal published agreements. We must be able to consistently capture the inputs, and accurately report on the adherence or non-compliance to the agreed SLM objectives. We must have organization buy-in and a full understanding of SLM through official ITIL© material, or appropriate training in the SLM discipline.
SLM is the key to all processes and functions in ITIL©. The common area in SLM is Service Level Agreements (SLAs. We will use Incident Management and Service Request Fulfillment to implement this:
Agree and publish Service Level Agreements for Incident Management response times and resolution times. The following table provides an example of the SLM inputs for five categories (priority) of incidents based on urgency and impact. The second table provides an example of the SLM inputs for the Service Request Fulfillment:
Incident Priority
Target first response
Target resolution time
1
30 minutes
4 hours
2
2 hours
8 hours
3
8 hours
24 hours
4
16 hours
80 hours
5
24 hours
120 hours
Service Request priority
Target first response
Target implementation
1
8 hours
16 hours
2
16 hours
24 hours
3
24 hours
72 hours
Install and configure an appropriate ITSM tool with SLM implementation capabilities (for example, SCSM).
Configure the tool with the details of the organization SLM requirements.
Capture the SLM metrics. Examples of some incident metrics are as follows:
Number of SLA breaches
Average time to resolve incidents
Number of incidents per week/month/quarter
Monitor the operational adherence to the SLM metric.
Report and adjust the appropriate execution of the processes to ensure adherence is in line with the agreed SLM objectives.
Service Level Management is what we use to ensure that IT capabilities are aligned with customer expectations of the services provided by IT. The successful implementation of SLM involves creating agreements between the supplier of services (IT and supporting third parties), and the consumer of the services (business customers). A driver for successful SLM is when an organization commits to compliance with industry-recognized standards. The following standards are typical drivers:
ISO 9001
ISO 27001
ITIL© certification
The overall goal is to ensure services are delivered at the right cost to the expectations of the service consumers. SLM is at its most effective when we create credible agreements, report proactively on performance of the service, and accurately capture the service consumer's feedback (for example, using customer satisfaction surveys).
Technically, all ITSM processes in this chapter can be implemented independently in SCSM. Based on best practice, an order of implementing the process is recommended.
A general understanding of the objectives of ITSM frameworks is required for this recipe. Also, a basic understanding of all ITSM processes described in this chapter is required.
The following figure provides a diagram of information flow, trigger options, and relationships between the ITSM processes in SCSM:
The order of implementing the different ITSM processes in SCSM depends on the requirement of each individual organization, which might differ. In general, some combinations and orders of ITSM processes are a best practice to the successful implementation of SCSM.
Option 1:
Configuration Management
Incident Management
Problem Management
Option 2:
Configuration Management
Service Request Fulfillment (Service Catalog)
Option 3:
Configuration Management
Incident Management
Combination of the following:
Problem Management
Change Management
Release Management
Option 4:
Configuration Management
Incident Management
Combination of the following:
Problem Management
Change Management
Service Request Fulfillment
Release Management
The Incident Management and Service Request Fulfillment are typically supported by the Service Level Management (SLM). SLM provides information on the Service Level Agreements (SLAs) for the respective processes.
The Configuration Management process with the Configuration Management System (CMS also commonly known as the Configuration Management Database (CMDB, provides technical information and details for all IT components (Configuration Items, CIs) for all other ITSM processes in SCSM. In addition, all ITSM processes update the CMS/CMDB with relevant information as each process is executed during its life cycle.
Incident Management is responsible for the fast remediation of disrupted IT services. Information from the Incident Records (Incident Ticket) can be used in the Problem Management process as related Problem Records. This is helpful in order to create workarounds, create Known Errors, discover the root cause of an incident, and optimize the IT services.
The Incident Management and the Problem Management processes can trigger required changes of an IT services. These changes are logged in Change Records in Change Management. A Change Record will contain different types of related activities (Review Activities, Manual Activities).
If the change is approved and all related activities in the Change Management process are completed, Release Management is responsible for rolling out the change to the affected IT service components. This will be logged as a Release Record with all the related activities of the roll-out.
An incident can also trigger a Service Request to provide a new service. For instance, an incident with the issue Can't open a file because of missing application on a client computer can be resolved by a Service Request to install the required application on the client computer.
The Service Level Management with defined Service Level Agreements supports the Incident Management and Service Request Fulfillment processes to monitor and report on the agreed SLM objectives.
