From Help
Jump to: navigation, search

ITSM Frameworks and Processes

Return to Main Page

Creating an Asset Management process

How to do it

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. It should capture the following:
    • IT Asset type
    • Financial information
    • Align the IT asset to its financial data
    • 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)
  • Continually review the policy and operational process. The goal of this step is to improve the process and ensure compliance.

How it works

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

  • Damaged goods
  • Missing goods

IT asset management is the stocktake 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 percent of the Asset Management for the organization. People and process critically account for the high value 20 percent.

There's more

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 decommission. Asset Management is an end-to-end process, and the tools are enablers of successful implementation. The successful Asset Management organization programs recognize the full life cycle management of assets.

Return to Top

Creating a Configuration Management System (CMS) process

Getting ready

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)

How to do it

An example of the steps for creating 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 the data from OpsMgr with SCSM.

How it works

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 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 2008)
  • 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 other 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.

Return to Top

Creating a Service Request Fulfillment process

Getting ready

Service Request Fulfillment is typically a process put in place to support a proactive approach to providing services to customers.

How to do it

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. An example of two category types are:
    • 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

How it works

A Service Request Fulfillment process aims to address the proactive goals of ITSM. Some of the common objectives when establishing this process are to:

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

Return to Top

Creating an Incident and Problem Management process

Getting ready

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

How to do it

Incident Management

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:
    • 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.
    • Automated or end user self-service created incidents (end user web portal, e-mail, or automatic system event driven).
  • 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.
  • Monitor and report on the performance of the incident management process. The aim is to improve the process and also identify incidents which require Problem Management.

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.

How it works

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. Continuing with our scenario from Incident Management:

  • The desktop engineering team identify the issue as a network hardware device failure in the laptop.
  • The team also identify that this issue has been happening to a number of laptops over the last quarter.
  • The team also identify through asset management that we purchase 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 close. A final best practice will be to create a knowledge article about this known issue and its corresponding fix.

Return to Top

Creating a Change and Release Management process

Getting ready

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.

How to do it

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 services: infrastructure services, messaging, 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 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 have 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
    • Resubmissions

How it works

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 it impacts 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 learnt (Knowledge management)

There's more

Release Management can be:

  • 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. Best practice for creating the process is; you should plan to assign a release management expert. The process should also have a supported agreed organizational policy.

Return to Top

Creating an IT Service Desk process

Getting ready

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.

How to do it

There are three main types of service desks:

  • Local Service Desk: Service desk in each customer 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 on 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 (SLA) and Operational Level Agreements (OLA)
  • Report on customer trends and service desk performance

How it works

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

  • Act to lower the total cost 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.

Return to Top

Service Level Management process

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.

Getting ready

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.

How to do it

SLM is the key to all processes and functions in ITIL©. The common area in SLM is Service Zevel Agreements (SLA). We will use Incident Management and Service Request Fulfillment as our functions in how to do it:

  • 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 Level 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 160 hours
Service Request Priority Target First Response Target Implementation
1 8 hours 16 hours
2 2 hours 24 hours
3 24 hours 72 hours
  • Install and configure an appropriate ITSM tool with SLM implementation capabilities (for example, System Center Service Manager).
  • Configure the tool with the details of the organization SLM requirements.
  • Capture the SLM metrics. Examples of some incident metrics are:
    • 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.

How it works

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

Return to Top


Microsoft System Center 2012 Service Manager Cookbook

Return to Top