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:

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:

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.

The authors recommend that you read the Understanding ITSM frameworks recipe.

Plan to do one or more of the following:

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:

The official phases of ITIL© are as follows:

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.

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:

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:

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 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:

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:

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:

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.

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:

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:

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.

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.

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:

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 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.

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:

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:

Release Management can be as follows:

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:

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:

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:

Here are the common functions the Service Desk should aim to perform:

The service desk process, once established, should deliver the following:

A service desk should aim to provide a unified and simplified experience to the customers it serves.

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:

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:

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).

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:

Option 2:

Option 3:

Option 4:

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.