ITIL Foundation Online Training - $47/mo Description: 14+ Hours, 200+ Practice Questions, Lifetime Access, 100% Online, Self-paced Click Here

10 Full ITIL Mock Exams for only $25/mo.Check if you are ready to take the ITIL Exam and crack it in the first attempt Click Here

Saturday, March 17, 2012

The Deming Cycle

Many organizations attempt Service Improvement through ‘Big bang’ implementations and by the utilization of large projects. This may be appropriate, but often small iterative step improvements to a service or process can be more efficient and less risky.
The Deming Cycle was introduced by W. Edwards Deming as a method for quality improvement. If processes are in place, they can be measured. Changes can be made to those process and the impact of the changes assessed via further measurement. This enables ongoing measurable improvement.

Over time the step improvements enable the service or process to become more mature. After each phase of Plan, Do, Check, Act, there is a period of consolidation to enable new improvements to ‘bed-in’ and to ensure that they are doing what they were intended to do.

The Deming cycle can be explained using the picture below:

The Goal of Deming cycle:

The goal is Continual Service Improvement. This relates to the services provided by the organization and also to the processes used to deliver those services. The Deming Cycle may be used to improve, for example, an online ordering service or the Service Level Management process within an organization.

Activities in the Deming Cycle

1. Plan - Planning the Improvements. Measures for success are agreed. Gap analysis is undertaken and a plan produced to close the gap through a series of step improvements.
2. Do - Implementation of Improvements. A project is instigated and conducted to implementation to close the gaps identified in the Plan phase. The project may include a number of step changes to improve a service or process.
3. Check - Monitoring, Measuring and Reviewing. The results of the implemented improvements are compared with the measures for success identified and ratified in the Plan phase.
4. Act - Improvements implemented. The improvements that have been identified are fully implemented.

The Deming Cycle can be used in order to improve any of the Service Management processes.

Prev: The 7 Step Improvement Process

The 7 Step Improvement Process

The following are the steps in the 7 step improvement process:

Step 1: Define what you should measure

Take into account vision, strategy, goals and objectives to determine what to measure. These measurements should enable the provider to demonstrate value to the business by linking back through to key business drivers.

Step 2: Define what you can measure

There may be a gap between the capabilities of current tools and mechanisms to provide the necessary information. If the desired data really cannot be gathered or if the cost is prohibitive, the measures in Step 1 may need to be revisited.

Step 3: Gather the data

Use monitoring to gather the data. Monitoring may be either automatic or manual. Extra care needs to be taken to ensure that manually gathered data is accurate and consistent.

Step 4: Process the data

Convert the data gathered into the required format for the audience. This can be seen as turning data into information.

Step 5: Analyse the data

Transform the information into knowledge. Develop an understanding of the real meaning of identified patterns and trends, by querying the results to understand its intrinsic value.

Step 6: Present and use the information

Communicate the information at the right level of detail for the audience and in a format that is understandable, provides value and will support informed decisionmaking.

Step 7: Implement corrective action

Use the knowledge gained to make the necessary changes throughout the lifecycle.

Prev: The CSI Manager

Friday, March 16, 2012

The Continual Service Improvement Manager

Everybody within the organization has a role to play in continual improvement. The key role that is essential to the effective implementation of this process is the CSI Manager.

This is role of real responsibility and either needs to have the appropriate seniority and authority or have clear and unambiguous senior support.

The Responsibilities of the CSI Manager include:
• Developing the CSI domain
• Communicating the vision of CSI across the organization
• working with the Service Owners and Service Level Manager to define the monitoring requirements, identify and prioritize improvement opportunities and establish Service Improvement Plans (SIPs)
• Identifying frameworks, models and standards that will support CSI activities
• Ensuring that activities are coordinated throughout the entire Service Lifecycle
• Presenting improvement recommendations to senior management

There is also likely to be an analyst who will be responsible for gathering and manipulating data, and presenting it in the desired formats.

Prev: Objectives of 7 Step Improvement Process

Next: The 7 Step Improvement Process

Objectives of the 7 Step Improvement Process

The objectives of the Seven-step Improvement Process are to:
• Define a set of measures that are relevant to business requirements and which will support the identification of effective improvement opportunities;
• Adopt a structured approach to gathering, processing and analyzing the measurement data in order to identify improvement opportunities;
• Communicate those improvement opportunities so that appropriate decisions can be taken about actions.

The Seven-step Improvement Process is fundamental in supporting CSI and operates across the entire Service Lifecycle. It focuses on identifying improvement opportunities, not only for the processes and services, but also for the disciplines implemented as part of each of the Lifecycle stages, including the discipline of CSI itself.

Value is created by ensuring that the services and the mechanisms for delivering those services continue to align with and meet business requirements, and by identifying opportunities for continual improvement.

Prev: Metrics used in Incident Management

Next: Objectives of the CSI Manager

Metrics used to measure Incident Management Efficiency

The following metrics can be used to measure the efficiency/effectiveness of Incident Management:
• The percentage of Incidents resolved within SLA
• The average cost of an Incident
• The average cost of a Major Incident
• The percentage of Incidents that are Major

Additionally, from a staffing point of view, it is important to know the volume of both Incidents and Major Incidents. On their own, these metrics do not necessarily give a measure of effectiveness or efficiency, but they are important in understanding the scale of the issues being raised.

The Incident Manager

The Incident Manager is responsible for the effectiveness and efficiency of the Incident Management process. First-line support is conducted by the Service Desk with second- and third-line support being provided by technical teams either internal to the organization or via third parties.

Relationship with other Service Management Processes

Incident Management is closely linked to Problem Management with one or more Incidents being caused by a Problem. There is also a strong link with Change Management. Changes are often implemented to resolve an Incident or a number of Incidents and, unfortunately, Changes that do not do exactly what they were intended to do may cause Incidents. Configuration Management provides the information needed to manage Incidents. Service Level Management will provide the target resolution times together with escalation criteria.

There is a very real difference between Incident Management and Problem Management. Incident Management is solely focused on restoring service as quickly as possible while Problem Management’s aim is to understand and tackle the root cause. This can lead to tension between the two processes.

Prev: Incident Management process flow

Next: Objectives of 7 Step Improvement

Incident Management process flow

The Incident Management process flow includes the following steps:

1) Inputs to the process: Incidents can be detected and reported in various ways. Users will call the Service Desk to report Incidents. Technical staff may log Incidents or email details of an Incident they have identified to the Service Desk. Increasingly Incidents are raised via web interfaces. The Event Management process will also report Incidents by monitoring.
2) Incident identification: Work to understand and resolve Incidents cannot start until an Incident has been identified. For this reason, monitoring of the components that make up key services is essential. Incidents can be identified in various ways by users, technical staff and by monitoring.
3) Incident logging: All Incidents must be logged with the date and time being recorded. At this stage, the information required to manage the Incident will be logged. This will include a unique reference number, a description of symptoms, the Service or CI impacted the impact, its urgency, and the name of person raising the Incident or the method of raising the Incident.
4) Incident categorization: A suitable categorization code will be allocated. For example, this may be hardware or software with sub-codes for lower level categorization. Accurate categorization is important because it will allow useful metrics to be gathered highlighting areas of the infrastructure where Incidents are occurring.
5) Incident prioritization: The priority of an Incident is based on the impact and the urgency. Impact is the ‘pain’ to the business. Impact may relate to the number of users impacted, the potential financial loss to the organization, and the risk of breach of regulatory or legislative rules or, for some services, the risk of loss of life. Urgency relates to how quickly the business requires the Incident to be resolved. Target resolution times will have been allocated to each Priority level. These will have been agreed with the business and recorded in the SLA.
6) Initial diagnosis: If the Incident has been raised by a call to the Service Desk, then it will be the Service Desk who conduct the initial diagnosis, usually while the user is still on the telephone. The availability of diagnostic scripts will help as will the ability to match against Problems and Known Errors. The CMDB may also be consulted at this stage.
7) Incident escalation: Escalation may be functional or hierarchical.
a) Functional escalation occurs when the Service Desk is not able to resolve the Incident or where the Incident has not been resolved within the target resolution time. The Service Desk will involve second-level support, which has more specific technical knowledge. Further functional escalation may occur through the lifecycle of the Incident to third-level support, which may be part of the organization or third parties such as suppliers. It is important to remember that the ownership of an Incident always remains with the Service Desk regardless of which other support areas are working on a resolution.
b) Hierarchical escalation raises the profile of a specific Incident within the IT organization and also within business areas. More senior IT staff are able to provide focus and resources, but ownership of the Incident will be retained by the Service Desk. Organizations will have triggers that indicate when hierarchical escalation is required. This may be for all ‘Priority 1’ Incidents or when Incidents of a certain priority have not been resolved with a target timescale. The triggers for escalation will be recorded in the relevant SLA and ought to be highlighted by the support tool in use. The Service Desk will keep the user informed of all functional or hierarchical escalations that occur during the lifecycle of an Incident and at the same time the Incident record will be updated.
8) Investigation and diagnosis: In this phase of the Incident lifecycle, work is undertaken by the Service Desk or support areas to understand what has to be done in order to restore service. This is often the most time-consuming part of the process although it can be speeded up using diagnostic scripts and by reference to other Incidents and Problems as well as Known Error databases.
9) Resolution and recovery: The investigation and diagnosis phase will arrive at a resolution. This needs to be applied and then testing needs to take place to ensure that the Incident has been resolved and service restored. There may be a time lag between a fix being applied and the service running normally again (e.g. there may be a backlog of processing to catch up on). On other occasions, it may not be possible to ascertain whether the fix has worked for a period of time (e.g. if the original issue was with a month-end process). Regardless of where the resolution has been put in place or who was involved, the Incident should be passed back to the Service Desk for closure.
10) Incident closure: Only the Service Desk should close Incidents. They need the user’s agreement that the Incident has been resolved. All Incident documentation will have to be completed prior to closure and a closure category allocated to allow meaningful metrics to be produced. User satisfaction surveys ought to be conducted for an agreed (in the SLA) percentage of Incidents. These user satisfaction surveys can be undertaken via telephone, email or web interface.

The whole process is summarized in the picture below

Prev: More on Incident Management

Next: Metrics used in Incident Management

More on Incident Management

The following are some important concepts you need to know about Incident Management


Timescales for Incident handling and triggers for escalation must be agreed and documented in the SLA. Performance against SLA can then be measured and reported. Tools can be configured to enable automated escalation in accordance with the agreed timescales.

Incident Models:

The adoption of Incident Models is a method of standardizing and automating, if possible, the approach to groups of similar Incidents. An Incident Model is a defined set of steps to be undertaken. Incident Model details can be input into the Incident handling tools.

Major Incidents:

Different organizations will have different definitions for what constitutes a Major Incident. For some organizations, the trigger for ‘calling’ a Major Incident is when a certain number of users have been impacted. For other organizations, the trigger may be the actual or potential financial loss from the loss of service. If the actual or potential financial loss is over a certain amount, the Incident becomes Major. For some business areas in some industries, there may be risk of injury or loss of life if particular services are not available. Again, this may be the trigger for the Incident becoming Major. Reputational damage to the organization can be another trigger.

Larger organizations may have dedicated Major Incident Management teams available 24/7 who take control of Incidents that have been designated Major. One of the important roles that Major Incident Managers undertake is to protect those (frequently IT Operations Management, Technical Management and Application Management staff) who are trying to restore service from the communication demands being made on them. During a Major Incident, there will be many demands and requests for updates which need to be managed. Major Incident Management teams will have established routes for communication and escalation.

A Major Incident Management process is similar to the Incident Management process, but is progressed with greater urgency and with higher profile within the organization. Activities undertaken must still be logged, but the focus is on restoring the service as quickly as possible with the minimum of disruption.

Prev: Introduction to Incident Management

Next: Incident Management Process Flow

Introduction to Incident Management

Incident Management is the Process for dealing with all Incidents. These may be Incidents where service is being disrupted or Incidents where service has not yet been disrupted.

The value of Incident Management to the business is that resources are allocated to minimizing and mitigating the impact of Incidents and service unavailability in line with business priorities. Lower levels of Incidents and quicker resolution times will enable the services to run as intended.

During the handling of Incidents, the Service Desk may be able to identify improvements in both business and technical processes. The Service Desk often has a unique position within organizations in that its staff can take a holistic view of how the organization operates, allowing good practice to be propagated and bad practice to be eradicated.

The main goal of the Incident Management process is to restore normal service operation as quickly as possible and to minimize the adverse impact on business operations.

Before we go any further about Incident Management, let us look at the official definition of an Incident.

An Incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a Configuration Item that has not yet impacted service is also an Incident.

Prev: Important Concepts in Access Management

Next: More on Incident Management

Important Concepts in Access Management

Access Management is the process of controlling access to data and information to ensure that authorized users have timely access while preventing access by unauthorized users. The Access Management process may be the responsibility of a dedicated function but is usually carried out by all Technical and Application Management functions.

If the Service Desk is operating as the single point of contact, it is usual that it should receive any Service Requests for new or changed access rights and may also be authorized by the owner of the security policy to grant these rights. Typically this occurs when a new person joins the organization or a new supplier is engaged, but it may also occur when someone moves from one department to another or changes role. Access rights should be withdrawn when someone leaves the organization.

The Access Management process should include monitoring access to secure information so that in the event of a security-related incident arising, the cause can be traced and any security risks discovered can be removed. Monitoring will also identify unauthorized access attempts and instances of password errors as indications of possible security threats.

Role of an Access Manager

The Access Manager or Access Control Manager is the individual who is responsible for controlling access to all resources within the organization. This may include access to offices, computers, data centers, shared drives, etc
Every request to gain access to a resource related to a service will be approved/rejected by this Access Control Manager. Periodic reviews of the usage of accesses will also be done to ensure that unwanted permissions are revoked as and when required.

Prev: Purpose of Access Management

Next: Introduction to Incident Management

Purpose of Access Management

Access Management is concerned with the management of people’s rights of access to information, and as such has common purpose not only with Information Security Management, but also with Availability Management, giving practical effect to the policies and requirements of both processes. Its goal is to ensure that the confidentiality, integrity and availability of information are effectively managed across the organization. Data and information must not only be protected against unauthorized access and the possibility of it being stolen or changed. It must also be readily available to those who are authorized to access it.
A key part of Access Management is the management of people’s rights to access information and services. People who have the right, in terms of business policy and need, to access information should have that right implemented through access controls. These rights must be consistent with relevant legislation such as data protection legislation, and must be kept under review and changed or revoked when a person’s status changes within the organization, or when a material risk is identified.

In order for access rights to have proper effect and value, Access Management must ensure that people can be properly identified: that each person has a unique identity to which their rights can be attached and to which activities, legitimate or otherwise, can be traced. Identity management is critical to effective Access Management, preventing, for example one person from pretending to be another and hijacking their rights to access and change information or, some would say even more importantly, to create new information. Organizations must take action to manage circumstance where access controls may be bypassed, for example where software developers require access to live systems during Incident Management.

The security objective of an organization is usually considered to be met when the availability, confidentiality, integrity and authenticity and non-repudiation are under control. These are defined below:
Availability - Information is accessible and usable when required and the host systems can resist attacks and recover from or prevent failures.
Confidentiality - Information is observed by or disclosed only to those who have a right to know.
Integrity - Information is complete, accurate and protected against unauthorized modification.
Authenticity - Authenticity concerns the correct labeling or attribution of information to prevent, for example, the originator of an email making it appear that the email came from another person. Authenticity is about ensuring that business transactions, as well as information exchanges between enterprises or with partners, can be trusted.
Non-repudiation - The mechanism that prevents the originator of a transaction falsely denying that they originated it or prevents the receiver falsely denying having received it.

Prev: Introduction to Access Management

Next: Important Concepts in Access Management

Introduction to Access Management

The Information Security Management process defines the Security Requirements that need to be enforced in the Service. However, Access Management is the actual process that governs the implementation of the security policy. Here, who needs to access to what, when, where etc are decided and implemented.

The main aim is to ensure that, only the right people have access to the right resources. This is done to ensure that, unauthorized individuals do not have access to resources meant for a different purpose. For ex: would you be ok if some random stranger can walk into your office and use the computer next to you?

Prev: Relationship between Security Management & other processes

Next: Purpose of Access Management

Relationship with other Service Management Processes

To one extent or another, all other processes interface with Security Management.

Availability Management

Information Security Management is a key contributor to Availability Management because without the right level of protection, the availability and integrity of data and systems is compromised.

Service Desk

The Service Desk usually has the authority to respond to requests for changes to access rights and passwords and therefore contributes to the operational management of security.

Other Processes

Other process interfaces are with:
• Incident and Problem Management - response to and resolution of security-related issues
• IT Service Continuity Management - a design consideration and a risk during testing
• Change Management - impact assessment on security controls
• Configuration Management - assistance with security classification for CIs
• Capacity Management - when introducing new technology
• Supplier Management - to ensure maintenance of security controls for operational activities carried out by third parties

Prev: IT Security Manager

Next: Introduction to Access Management

Role of IT Security Manager

The IT Security Manager is responsible for defining the Information Security Policy and establishing the ISMS. Once these are in place, it is the IT Security Manager’s job to ensure that all the proper controls are in place, people are aware of the policy and their responsibilities and that the security system is functioning correctly. The IT Security Manager is the focal point for all security issues.

Service Operation teams are responsible for conducting day-to-day activities to manage operational security. It is important that these roles are kept separate from those of Security Management to prevent a conflict of interest. Operation roles include:
• Policing and reporting
• Providing technical support and assistance
• Managing security controls
• Screening and vetting individuals
• Providing training and awareness
• Ensuring that security controls are appropriately referenced in operational documentation.

Metrics used in Information Security Management

Security Management metrics are needed to ensure that the organization can meet both internal and external security requirements found in SLAs, contracts, legislation and governance. Metrics that can be used for this purpose include:
• The number of security-related Incidents per unit of time
• The percentage of security-related Incidents that impacted services or users
• The number of security audit issues and risks identified
• The percentage of security audit issues and risks resolved
• The number of changes and releases backed-out because of security issues
• The average time to install security patches

Prev: Controlling Access to Facilities

Next: Relationship with other Processes

Controlling Physical Access to Facilities

Remember the example about additional layers of control and protection for projects handling bank data? What I was indirectly referring to was access to physical facilities like office building, computers etc.

Information Security Management defines the access control policy, and identifies the necessary physical security measures and who should have access to which site (e.g. the data centre). Facilities Management is responsible for enforcing this policy. The major components of physical access control are:
• The installation, maintenance and management of physical access security controls such as locks and barriers and surveillance equipment
• Monitoring of physical access to protected areas
• Physical security staffing
• Maintenance of floor plans showing areas of restricted access and the relevant security controls.

One of the most common means of breaching physical security is by ‘social engineering’: a rather grandiose term that usually refers simply to talking your way into a secure facility (e.g. by posing as a legitimate contractor, posing as someone else or simply following a legitimate person through an open door). For this reason, security access must not only be controlled appropriately but also continually monitored so that such breaches can be detected and security controls improved. This activity can also be considered a sub-set of the Access Control Management process group.

Prev: Important Concepts

Next: Role of an IT Security Manager

Important Concepts in Information Security Management

The following are some concepts that you need to know about Information Security Management for the ITIL exam.

Information Security Policy

The Information Security Policy should support and be aligned to the business security policy. It should include policies covering the use of IT assets, email, the internet, important documents, remote access, access by third parties (such as suppliers) and asset disposal. In addition, it defines the approach to resetting passwords, maintaining anti-virus controls and classifying information. These policies should be available to all customers and users as well as to IT staff, and compliance to the policy should be referenced in all internal agreements and external contracts. The policy should be reviewed and revised on at least an annual basis.

Information Security Management System

The Information Security Management System (ISMS — also referred to as the Security Framework) helps establish a cost-effective security program to support business objectives. The objective of the ISMS is to ensure that appropriate controls, tools and procedures are established to support the Information Security Policy.

The image below shown an example framework widely used and based on the ISO 27001 standard that gives the five stages of the ISMS and the scope of each stage.

Prev: Goals, Purpose & Objectives

Next: Controlling Access to Facilities

Goals, Purpose and Objectives of Information Security Management

In the previous chapter, we learnt what the Information Security Management process is. In this chapter, let’s learn about the goals, purpose and objectives of this process.

Goal of Information Security Management

The goal of the Information Security Management process is to make sure that IT security is consistent with business security, ensuring that information security is effectively managed in all service and Service Management activities and that information resources have effective stewardship and are properly used. This includes the identification and management of information security risks.

Purpose of Information Security Management

The purpose of Information Security Management is primarily to be a focal point for the management of all activities concerned with information security. This is not just about protecting information resources today. It is about putting in place, maintaining and enforcing an effective Information Security Policy. It is about understanding how the business will develop, anticipating the risks it will face, articulating how legislation and regulation will affect security requirements and making sure that Information Security Management is able to meet these challenges of the future.

Objective of Information Security Management

The objective of Information Security Management is to ensure an effective Information Security Policy is in place and enforced through effective, documented security controls that apply not only to in-house employees, but also to suppliers and others who have business/contact with the organization. It must ensure that any security breaches are managed promptly and effectively, and that risks are identified and documented and lessons are learned accordingly.

Prev: Information Security Management Introduction

Next: Important Concepts

Introduction to Information Security Management

The security of data and information is of vital importance to any organization and it is therefore a business decision as to what information should be protected and to what level. The business’s approach to the protection and use of data should be contained in a security policy to which everyone in the organization should have access and the contents of which everyone should be aware. The system in place to enforce the security policy and ensure that the business’s IT security objectives are met is known as the Information Security Management System (ISMS). Information Security Management supports corporate governance by ensuring that information security risks are properly managed.

If you have worked in an IT company that provides IT services to a Bank or any other Financial services company, you will have seen this in real life. Offices where projects for banks or financial services companies are executed are protected with an additional layer of security with strict rules or do’s and don’ts for all employees.

Prev: Key Activities in Operations Management

Next: Goals, Purpose & Objectives

Key Activities in Operations Management

IT Operations Management is made up of two parts:
1. Operations Control - Responsible for carrying out the day-to-day operational activities. This includes monitoring the IT infrastructure and applications and responding to Events, Incidents and Problems. More specifically tasks include Job Scheduling, Backup and Restore, Console Management, Print and Output Management as well as undertaking maintenance activities for Technical Management teams and Application Management teams.
2. Facilities Management - Responsible for the day-to-day management of the physical IT environment. This typically would include responsibility for the data centre, server rooms as well as recovery rooms and sites. The power supply and back-up power supply would also be in scope. If any part of the physical IT environment is outsourced, then the Facilities Management arm of IT Operations Management would be responsible for day-to-day management of the contract and the relationship with the supplier.
It is important that IT Operations Management is involved at the right time throughout the Service Management lifecycle and in the right way.

IT Operations Management is involved in the following way with the various stages of the lifecycle.

During Service Strategy:

IT Operations Management will have an in-depth understanding of how current technology is used to deliver existing services. This understanding, together with an awareness of new and emerging technologies, allows IT Operations Management to have a meaningful input to the Strategy phase of the Service Management lifecycle. It is crucial that those responsible for Strategy use the knowledge that is available about how services are actually delivered on a day-to-day basis.

During Service Design:

Carrying out the activities set out in the Service Design phase is the responsibility of IT Operations Management. Therefore, it is important that IT Operations Management has the ability to input to this phase.

During Service Transition:

Testing is an area of Service Transition where you would expect IT Operations Management to be involved heavily. IT Operations staff have the knowledge and understanding of the live environment, which allows them to ensure testing is correctly designed and executed. It may well be IT Operations staff, under direction from Service Transition, who physically introduce Releases to the live environment and monitor their progress.

During Service Operation:

This is the fundamental task of IT Operations Management. They maintain and monitor the components (infrastructure and applications) that underpin the services and react in a timely fashion to Events, Incidents and Problems identified.

During Continual Service Improvement:

Staff from IT Operations Management will always be looking for ways to improve the services and boost efficiency and effectiveness.

Prev: Introduction to Operations Management

Next: Introduction to Information Security Management

Introduction to Operations Management

IT Operations Management is a Function and not a Process. It is responsible for operating the organization’s IT infrastructure and applications on a day-to-day basis. The IT infrastructure and applications underpin the organization’s services.

Delivery of stable service with unavailability minimized is the main goal of Operations Management. IT Operations Management is the function that ensures that all the organization’s IT infrastructure and applications are managed and maintained on a day-to-day basis in order to deliver the agreed levels of service.

Relationship with other Service Management Processes

There may be overlaps between IT Operations Management and both Technical Management and Application Management. IT Operations Management is a distinct function but it is usual for teams from both Application Management and Technical Management to be part of this function.

Technical Management is responsible for the IT infrastructure while Application Management is responsible for applications. Technical Management has the same responsibilities for the IT infrastructure as Application Management has for applications.

Prev: Relationship between Financial Management and other Processes

Next: Key Activities

Relationship with other Service Management Processes

IT Financial Management is central to IT Service Management, and it has links with many of the other Service Management disciplines. They are:

Service Level Management

Service Level Management (SLM) needs to work with Financial Management in relation to the costs of proposed levels of service required to meet the organization’s current and planned business needs. These costs will feed into the debate about what is affordable and deliverable and, therefore, what can be agreed in Service Level Agreements (SLAs). If charging is in place, Financial Management will be involved in determining charges, including the use of differential charging as part of Demand Management. Financial Management will assist in costing changes and evaluating new investments required to meet business needs.

Service Portfolio Management

Financial Management is concerned with business case development, assessment of investment opportunities, evaluation of different service options, the evaluation of financial risks and the determination of service value. All these are central to decisions about what should be included in the Service Portfolio or removed from it. Financial Management is able to contribute to decisions on how best to provision a given service, whether this should be through the in-house IT service provider or a third-party provider. Financial Management is also responsible for ensuring that funding is available to support the delivery of the Service Portfolio and for ensuring budget allocations align with it.

Capacity Management

Both Availability and Capacity Management are concerned with cost-effective delivery of services, and Financial Management can assist by providing costing information to enable assessment of the financial impact of desired levels of Capacity and Availability. Proposals to invest in new capacity or in increased resilience can be assessed by Financial Management before action is taken to purchase. Where charging is in place, Capacity Management will be able to provide information on resource usage that will help Financial Management determine charges.

Configuration Management

Configuration Management manages and maintains the Configuration Management Database (CMDB), which holds financial and other information on assets that are required by Financial Managements for a variety of uses. For example, from the CMDB, it should be possible to identify all the components required to deliver a given Service and this information is used by Financial Management to determine the overall cost of the Service. The CMDB also holds information on assets, such as equipment replacement dates and license termination/renewal dates, which can be used in budget development and longer-term financial planning.

Prev: Important Concepts in Financial Management

Next: Introduction to Operations Management

Important Concepts in Financial Management

The following are some important terms & concepts related to financial management

Service Valuation

Services are what the business sees and understands and if IT Financial Management adopts a service perspective, it will be using a language familiar to the business. Financial Management is concerned with quantifying the value of services and of the assets underlying their provision (Service Valuation). Service Value has two components: the Service Provisioning Value and the Service Value Potential. The first is the actual cost of provisioning the service. This ‘Provisioning Value’ is the sum of the actual costs of delivering the service. This has many similarities to the traditional cost model, where cost elements covering hardware, software, personnel, accommodation etc. are allocated to specific services. Generally, the Provisioning Value represents the minimum value of a service since providers will rarely wish to provide service where the full provisioning cost cannot be recovered. The Service Value Potential is the added value of the service based on what the customer perceives as the financial benefit. The total value of the service is the sum of these two parts. This provides IT and the business with a common language for understanding what IT delivers, what it is worth to the business and, if charging is in place, what a fair price would be.

Demand Modeling, Service Portfolio Management and Service Provisioning Optimization

Service Valuation information is used to forecast the cost of delivery against a pattern of changing demand (Demand Modeling). Financial Management provides financial information that enables the organization to understand the costs and efficiencies of services included in the Service Catalogue and to make decisions about the best way of provisioning these services (Service Portfolio Management and Service Provisioning Optimization).

Financial Management analyses data that enables the organization to translate service costs and patterns of demand into financial resourcing requirements. The total operating costs for the IT service provider will cover all delivered services included in the Service Catalogue, the costs associated with new and changing services in the Service Pipeline and any other costs not otherwise included in service costs. For organizations where financial planning is based on a fixed budget cycle, this information, along with information on expected income, will be translated into budgets.

Governance and compliance

Financial Management will also establish rules for sound financial governance. For example, many organizations will have rules controlling expenditure that will create longer-term financial liabilities. There may be controls over the recruitment of permanent staff because this creates a continuing liability for salaries or redundancy payments. The procurement of fixed assets may mean a continuing commitment for maintenance. Without these controls, an organization can easily build up problems for the future in the form of financial liabilities it cannot meet.

One responsibility of Financial Management is to ensure that the organization complies with all elements of the regulatory framework, including any requirements for statutory returns and reports. Financial Management establishes internal structures and processes, including internal audits, to ensure compliance. Part of this responsibility will concern monitoring expenditure and income against financial plans and budgets to make sure that things are going as planned. Any significant variations from what was planned and expected must be identified and dealt with before they put the organization at risk.


It is important to plan ahead to make sure that business plans match the money available. The product of this planning is a financial plan or budget covering expected expenditure and income for a specified period, usually a (financial) year. Expenditure and income will be divided into categories to facilitate financial planning, management and control.
The budget must reflect the services to be delivered, new projects, investments and other planned changes. It is not an articulation of what the business hopes to do: it is about what can be realistically achieved. Even so, a budget is a plan and plans do not always work out. Budgets should be the best prediction the organization can make, but should include some contingency for the unexpected.

Budgets should show how expenditure and income is likely to change during the budget period (e.g. higher labor and transport costs at seasonally busy times).

Sound financial management requires regular monitoring against budgets. It tells the organization when action is needed to maintain financial control, giving early warning that expenditure is too high or income too low; that planned projects cannot be funded or that others may be brought forward.


The processes in IT accounting allow the IT service provider to account for expenditure and income, providing a breakdown of how costs and income are divided between customers, services and activities. This analysis helps determine the cost-effectiveness of services to make sound decisions about them. It provides details of how costs can be attributed to customers and customer groups, allowing the organization to identify key customers and the impact of their service consumption. The information gathered through the Accounting Process provides budget monitoring with expenditure and income data, which will be used to evaluate the effectiveness of financial controls and to determine if action is required to rectify any significant variations from budget.


The decision whether to charge is a strategic decision to be taken with due care. Charging not only increases the operating costs of the IT service provider, but also increases accountability, exposure and transparency. Customers can compare what they get from IT with what they have to pay, and they can more easily compare their in-house IT provider with alternatives. Charging provides a means to influence customer behavior, shaping demand and usage to match capacity, thereby reducing costs and risk. Without charging, many customers and users will see IT services as free and will make demands on these services with little interest in the financial or operational implications. The introduction of charging helps change attitudes.

Service Investment Analysis

All organizations need to invest wisely and a key role of Financial Management is to evaluate proposals for investment to determine whether they are worthwhile.

Sound Financial Management will require all proposals for investment to include a clear case for making the investment. This case normally takes the form of a Business Case.

A Business Case is a decision support and planning tool that projects the likely consequences of a business action. The core of the Business Case is usually a financial analysis, but the justification of investments frequently depends on more than financial considerations.

Financial Management, in conjunction with business managers and other key stakeholders, will assess the business case in relation to the scale of the investment and the anticipated return, the impact on the business, the timescale for the realization of benefits, the risks and contingencies involved the robustness of the figures and their sensitivity to change. All of these should be covered in a sound Business Case.

It is essential that the Business Case makes it clear how the benefits and costs have been assessed, the assumptions on which it relies and the level of confidence in the figures. Business Cases sometimes depend on highly optimistic or even dubious views of the future, and it is crucial that this is made clear to the decision-makers. For example, it is common for Business Cases to predict staff savings based on individuals saving a few minutes of their time each day through a new investment. All these free minutes are aggregated, costed and presented as a benefit, even though there may be no practical way of realizing a financial saving. It will also evaluate the resource requirements and take a view on whether the organization has the resources and capabilities to deliver. An important concept is that of affordability. An investment may offer outstanding prospects, but the organization should not give approval unless it can afford it.

Prev: Goals, Purpose & Objectives

Next: Relationship with other Processes

Goals, Purpose and Objectives of Financial Management

In the previous chapter, we learnt what financial management is. In this chapter, we are going to learn about the goals, purpose and objectives of this process.

Goal of Financial Management

The goal of IT Financial Management is to ensure that optimal use is made of the organization’s financial resources and that this is achieved in compliance with the regulatory framework within which the IT service provider operates.

Purpose of Financial Management

The purpose of Financial Management is to ensure that:
• Money is managed and spent wisely
• The financial resources available align fully with the organization’s plans and requirements for IT service delivery
• Investment decisions are sound and relevant to the organizations objectives
• Financial risks are identified and managed effectively
• Governance arrangements are in place to ensure the effective stewardship of financial resources and to define clear accountabilities
• The organization complies with all relevant financial regulatory obligations and the overall financial policy and strategy of the business.
Objectives of Financial Management

The key objectives of this process are to ensure that:
• There is an effective system for financial planning and budgeting
• Financial plans and budget allocations are aligned with the Service Portfolio
• All proposed investments have a business case that meets the standards of the organization
• All significant financial risks are identified and fully managed
• There is an appropriate governance framework in place with clear accountabilities and all those who need to be are properly trained in relation to it
• All financial expenditure is properly accounted for and there is an audit process to ensure proper stewardship of financial resources
• The costs and value of all IT services, processes and activities are monitored, measured and understood and appropriate actions are taken on the basis of their financial performance.

Prev: Introduction to Financial Management

Next: Important Concepts in Financial Management

Introduction to Financial Management

Money – The Best and Worst thing invented by MAN. The purpose of running a business is to make money and generate profits. Like any other business, the IT service provider, whether run as a commercial business or not, needs sound financial management. It must ensure it has the right amount of money available to put its plans into action, to make sure that it understands how its money has been used, to determine if the money has been used effectively or whether a proposed new investment is sound. It needs to understand what individual services cost to deliver and how these costs should be divided among the service users, so that, among other things, it can assess the impact of changes in demand and levy charges for service use if appropriate.

Financial Management is about looking after the organization’s financial resources, making sure that they are prudently employed and that their use is properly accounted for. Financial Management makes sure the organization has an understanding of the costs of its operations, the structure of these costs and the things that influence them. It helps the organization make the best decisions about the services it should provide, the way services should be provisioned, the investments required for their delivery and the effect of changing patterns of demand. It evaluates the value of services to the business and, if relevant, a basis for setting prices for them. Working with Service Portfolio Management, it helps the organization determine the services it should provide and those it should discontinue or change in some way.

Financial Management helps with financial planning, making sure that the organization’s plans align with its ability to support the financial costs and manage the risks. It keeps track of expenditure so that it is clear how the money has been used. By routinely comparing expenditure and income with financial plans and budgets, Financial Management will identify potential problems and take appropriate action to keep the organization on track. Where the IT service provider charges for service, Financial Management will advise on how this should be done and what charges should be levied.

IT service providers must work in a rapidly changing world. Businesses, and the context in which they operate, are constantly changing, and the IT service provider must respond rapidly and effectively to these changes. Strong Financial Management enables the IT service provider to make better decisions and respond more rapidly to change. It enables better control over spending, ensures sound investment decisions and promotes value capture.

Prev: Relationship between ITSCM and other Processes

Next: Goals, Purpose & Objectives

Relationship with other Service Management Processes

IT Service Continuity Management interacts with the following processes:

Availability Management

There is clearly an overlap between the ITSCM process and the Availability Management process. The distinction is that Availability Management is primarily concerned with maintaining the availability of VBFs, whereas ITSCM provides contingency in the event of a failure that either Availability Management could not prevent or from which IT could not quickly recover.

Change Management

Changes need to be assessed for their impact on continuity plans and consequent changes incorporated into the change planning. The Continuity Plan itself is subject to change control.

Service Level Management

Service Level Management will provide advice on the definition of VBFs and the expectations of the business with regard to the permissible time delays in the restoration of services.

Capacity Management

Capacity Management helps to ensure adequate resources are available to accommodate services after the Continuity Plan is invoked and that agreed service levels can be maintained in this situation.

Asset and Configuration Management

Configuration Management maintains records of recovery CIs, their status and specification.

Information Security Management

The potential for a security breach to cause a major Incident means that Information Security Management contributes to the BIA and Risk Analysis activities.

Prev: Role of ITSC Manager

Next: Introduction to Financial Management

Role of an IT Service Continuity Manager

The IT Service Continuity Manager is responsible for ensuring that the objectives of the ITSCM process are met. His responsibilities will include:
• Undertaking BIA and risk management exercises for both existing and new services
• Implementing and maintaining the ITSCM process and continuity strategy and maintaining the alignment with business continuity planning
• Preparing and maintaining the continuity and recovery plans and ensuring that these continue to support the organization’s Business Continuity Strategy and plans
• Regularly testing the plans for effectiveness, reviewing the results and taking action to overcome any identified deficiencies
• Ensuring that any personnel who have a role in transitioning from one location to another are fully trained and aware of their responsibilities
• Managing third-party suppliers of recovery equipment and facilities to maintain the integrity of the continuity and recovery plans
• Attending Change Advisory Board (CAB) meetings as required and assessing changes for their impact on the plans and updating the plans accordingly
• Managing the continuity plan during invocation and restoring the service back to the primary or other designated facility.

Metrics used to measure ITSCM Performance

Metrics that can be used to measure the performance of the ITSCM service and process in respect of the effectiveness and preparedness of the organization are as follows:
• The number of services not covered by the continuity and recovery plans (that should be covered).
• The number of issues identified in the last continuity test that remain to be addressed.
• The number of errors found in an audit of the information in lists of key people, their responsibilities and contact details.

Prev: More on ITSCM

Next: Relationship with other Processes

More on IT Service Continuity Management

In the previous chapters, we learnt what ITSCM is and its goals & objectives. In this chapter, we are going to take a look at some of the key concepts of ITSCM.

The Service Continuity Management Lifecycle

Establishing and maintaining ITSCM is a cyclical process that ensures continued alignment with Business Continuity plans and business priorities. It is explained in the picture below:

The first two steps, Initiation and then Requirements and Strategy, mainly relate to BCM. ITSCM begins with producing an ITSCM strategy to underpin the BCM strategy. The ITSCM strategy must ensure that cost-effective plans exist to recover IT services and any required IT infrastructure necessary to maintain VBFs.

The situation is more complex where some or all of the IT services are outsourced to another organization. In this case, the ITSCM Manager must ensure that the outsourcer’s continuity and recovery plans meet the objectives and timescales of the business.

Business Impact Analysis

Business Impact Analysis (BIA) is the activity performed by ITSCM, often together with Availability Management, that works with the business to understand the impact on the organization of suffering degraded service or losing an IT service or component. The analysis will identify business functions that are critical to the success of the organization (VBFs) and it is these functions that ITSCM must protect from the impact of an IT failure. The business will define the recovery requirement for these functions that ITSCM must address through its IT continuity plans. Over time, the importance of business functions can change and new ones appear, so ITSCM must undertake regular BIA exercises and feed the results back into the continuity plans to ensure they remain appropriate and up to date.

Risk Analysis and Management

A Risk is - A possible event that could cause harm or loss, or affect the ability to achieve Objectives. A Risk is measured by the probability of a Threat, the Vulnerability of the Asset to that Threat, and the Impact it would have if it occurred.
The first step in protecting VBFs is to understand their dependency on the IT services and infrastructure. This information can be discovered from the Configuration Management System. Next, ITSCM must consider a number of factors:
• What could cause a service or component to fail? Examples can include fire, flood and security breaches in addition to simple mechanical or electrical failure.
• What is the likelihood of this happening? In other words, what are the chances that each of the events defined above could occur?
• What is the impact of such an occurrence? If one of the events did occur, what effect would this have on the business?

This might be expressed in terms of the impact on its reputation, its customers, its finances or its legal or compliance requirements, for example.

The outcome of these considerations will determine the appropriate actions ITSCM has to take to mitigate the risks adequately and cost-effectively. Typically, the greater the likelihood of failure and the greater the impact, the greater the level of protection needed and the greater the justification for the necessary expense.

The first stage of risk analysis and management is to identify potential threats to an asset or service, estimate the probability that the threat might materialize, assess how vulnerable the asset or service is to these threats and to assess the impact should the threat materialize. For example, as identified above, flood is one example of a threat that might be relevant to an asset such as a data center. We would determine the probability that the center might be flooded; assess the vulnerability of the data center to flooding and the impact on the organization if it did flood. Putting all these together would give us a measure of risk.

The second part of risk management is doing something about the risks identified. Generally, we can do a number of things about risks:
• Some risks can just be accepted and provision made in case the worst happens. If we cannot insure our data center because it sits in a flood plain, we may decide to hold a contingency fund in case it does flood.
• We can avoid or eliminate the risk; for example, we can eliminate the risk to our data center by deciding to go back to manual processing. This is not always a practical solution.
• We can transfer the risk to somebody else, for example by taking out insurance or by outsourcing the data center and disaster recovery.
• We can reduce the risk by reducing the probability of the threat or by reducing the severity if the risk materializes. For our data center we might move it to the top of a hill to reduce the probability of a flood or reduce the impact of a flood by replacing under floor cables with fiber optics.

In many cases, the response to risk will be a combination of all or some of these options, with a balance being established between the business’ tolerance to risks and the cost of countermeasures.

A key issue for IT Service Management and ITSCM in particular, is to have some way of analyzing and managing risk, and the best and safest approach is to use a tried and tested framework that covers all aspects of risk identification and management.

Prev: Goals, Purpose & Objectives

Next: Role of an ITSC Manager

Goal, Purpose & Objectives of ITSCM

In the previous chapter, we learnt what IT Service Continuity Management is. Now, let us learn the goals, purpose and objectives of this process.

Goal of IT Service Continuity Management:

The goal of ITSCM is to support Business Continuity Management by ensuring that the IT resources, systems and services can be reinstated within agreed timescales in the event of a major incident.

Purpose of IT Service Continuity Management

The purpose of ITSCM is to create and maintain the facilities and recovery capabilities needed to support this goal.

Objectives of IT Service Continuity Management

The objectives of ITSCM are:
• To create and maintain the IT Service Continuity Plans and recovery plans
• To carry out regular Business Impact Analysis (BIA) exercises to ensure that the plans remain aligned with changing business requirements
• To carry out regular Risk Analysis and Management exercises to determine the potential for failure and identify and implement appropriate responses that meet agreed business continuity targets
• To assess the impact of changes and take appropriate action to continue to provide the required level of protection
• To ensure that the appropriate third-party contracts and agreements are in place and kept up to date to maintain the continuity and recovery plans
• To proactively enhance recovery capabilities where it is cost-effective to do so
• To provide advice and guidance on continuity and recovery-related issues.

Prev: Introduction to ITSCM

Next: More on ITSCM

Introduction to IT Service Continuity Management

Most organizations’ dependency on their IT systems is such that the loss of key applications or infrastructure could cause the company to fail within days or even hours. Can you imagine an online trading website surviving even one hour, if their servers crash?

Because of this, organizations need to plan how they will recover their key systems within an appropriate timescale in the event of a failure. This is the focus of the IT Service Continuity Management (ITSCM) process.

Organizations can of course suffer from the loss of systems other than IT systems and should therefore have a general Business Continuity Plan that protects against any eventuality that could threaten its vital business functions (VBFs). ITSCM should therefore support and align with the organization’s Business Continuity Management (BCM) process where this exists.

Prev: Managers involved in SACM

Next: Goals, Purpose & Objectives

Role of Managers involved in SACM

Since SACM is a complicated discipline, it is practically not possible to have only one person In-charge of the whole process. As a result, a bunch of specialized individuals together share the responsibilities in SACM. They are:
Service Asset Manager – He manages the lifecycle of assets.
Configuration Manager – He manages the lifecycle and relationships of all CIs.
Configuration Analyst – He analyzes/proposes scope of asset and configuration processes; undertakes process activities.
Configuration Administrator/Librarian – He controls the receipt, identification, storage and withdrawal of all supported CIs (content control).
CMS/Tools Administrator – He monitors the performance and capacity of Asset and Configuration Management systems and recommends improvement opportunities (technical control).

Relationship with Other Service Management Processes

SACM underpins virtually every other Service Management process as we have already seen. The most significant relationships are:

Change Management: Identifying the impact of proposed changes
Financial Management: Capturing key financial information
IT Service Continuity Management: Providing awareness of assets the business depends on and controlling key spare assets and software
Incident and Problem Management: Providing and maintaining key diagnostic information and maintaining and providing data to the Service Desk
Availability Management: Supporting detection of points of failure.

Prev: Challenges & Metrics

Next: Introduction to IT service Continuity Management

Challenges & Metrics in SACM

Now that we know what SACM is, its Purpose & Objectives and Key Activities in SACM, we will now learn what the Challenges & Metrics in SACM are.

Challenges in SACM

Service Asset and Configuration Management can be one of the most difficult disciplines to introduce. Although it underpins virtually every aspect of Service Management, it is perceived as having little direct value itself. The following challenges are very common:
• Persuading technical support staff of the value of SACM because they may see it as a hindrance.
• Funding of SACM, because it is not visible to the business.
• Over-engineering and collecting too much data: getting the balance between what can be recorded and what needs to be.
• The CMS can become out of date as CIs are moved or changes are made. An out-of-date CMS is actually very dangerous since incorrect decisions can be made on the basis of the information.

Metrics used in SACM

Most of the metrics that indicate successful Configuration Management are actually seen in other processes. Some of the key ones are:
• The ratio of used licenses to paid for licenses (this should be close to 1 : 1)
• Accuracy in budgets and charges for the assets used by each customer or business unit
• The percentage reduction in business impact of outages and Incidents caused by poor Asset and Configuration Management
• The reduction in the use of unauthorized hardware and software, and in non-standard and variant builds that increase complexity, support costs and risk to the business services.

Prev: Key Activities in SACM

Next: Managers involved in SACM

Key Activities in Service Asset and Configuration Management

The key activities of Service Asset & Configuration Management are:

1. Management and Planning - Defining the level of Configuration Management required for a service or a change project
2. Configuration Identification - Defining CI types and groupings, naming conventions etc.
3. Configuration Control - Ensuring there are adequate mechanisms to control CIs while maintaining a record of all changes to ensure no mismatch with the physical world
4. Status Accounting and Reporting - Maintaining the status of CIs as they progress through their discrete states (e.g. Development, Approved, Live, Withdrawn)
5. Verification and Audit - Checking that the physical CIs exist, records in the CMS match the real world, and that documentation is accurate
6. Information Management - Back-up copies of the CMS should be taken regularly and securely stored. It is advisable for one copy to be stored at a remote location for use in the event of a disaster.

Prev: More on SACM

Next: Challenges & Metrics

More on Service Asset and Configuration Management

All of the information that we are interested in will be held in a repository known as the Configuration Management System (CMS) as a series of Configuration Item (CI) records, each of which has descriptive information (known as Attributes) including relationship data to other CIs. The CMS will typically consist of one or more Configuration Management Databases (CMDBs). Historically, there has often been confusion about this aspect, with many organizations striving to develop a single physical CMDB when it is the logical concept of a repository, the CMS, which is important.

Before we proceed any further, let’s take a look at the definition for some of the important terms that will be used in this topic.

Configuration Item:

A Configuration Item (CI) is any component that needs to be managed in order to deliver an IT service. Information about each CI is recorded in a configuration record within the Configuration Management System and is maintained throughout its lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and SLAs.

Configuration Model:

A Configuration Model is a model of the services, assets and the infrastructure that includes relationships between CIs, enabling other processes to access valuable information (e.g. assessing the impact of Incidents, Problems and proposed changes; planning and designing new or changed services and their release and deployment; optimising asset utilisation and costs).

Configuration Management System:

A Configuration Management System (CMS) is a set of tools and databases used to manage an IT service provider’s configuration data. The CMS also includes information about Incidents, Problems, known errors, changes and releases, and may contain data about employees, suppliers, locations, business units, customers and users. The CMS includes tools for collecting, storing, managing, updating and presenting data about all CIs and their relationships. The CMS is maintained by Configuration Management and is used by all IT Service Management processes.

Configuration Management Database

A Configuration Management Database (CMDB) stores configuration records containing Attributes of CIs and their relationships. A CMS may include one or more CMDBs.

Configuration Baseline:

A Configuration Baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, which thereafter serves as the basis for further activities and can be changed only through formal change procedures. A configuration baseline can be used to checkpoint a service development milestone, as a basis for future builds and changes, to assemble components for a change or release and to provide the basis for a configuration audit or back-out.

Definitive Media Library

A Definitive Media Library (DML) is one or more locations in which the definitive and approved versions of all software CIs are securely stored. The DML may also contain associated CIs such as licences and documentation. The DML is a single logical storage area even if there are multiple locations. All software in the DML is under the control of Change and Release Management and is recorded in the Configuration Management System. Only software from the DML is acceptable for use in a release.

CIs should be selected using established selection criteria, grouped, classified and identified in such a way that they are manageable and traceable throughout the Service Lifecycle.

One of the most challenging aspects of establishing effective Configuration Management is defining the most appropriate level at which CIs are defined. A balance must be struck between having sufficient information to be truly useful and the effort that is involved in collecting and maintaining the information.

Representing the components and their relationships pictorially can help greatly in reaching an understanding of what is required.

The CMS contains information about the logical software components, while the DML is a secure library which contains the definitive authorized versions of software approved for live use within the organization, regardless of their source. The CMS and DML are used together in the building of a Release prior to Deployment.

Software held in the DML will have passed quality assurance tests, demonstrating its integrity and its freedom from viruses. DML software can be trusted. As said above, the DML stores definitive versions irrespective of source and essential documentation. It therefore holds not only in-house developed software but also third party/purchased software, along with license documents or evidence of licenses purchased.

The DML must be secure, in terms of preventing unauthorized access, in terms of SACM controlling what comes into and goes out of the store and, critically, in terms of the physical security and safety of its contents in the event of fire, flood and so on.

Prev: Purpose & Objectives from SACM

Next: Key Activities in SACM

Purpose and Objectives of Service Asset and Configuration Management

In the previous chapter, we saw what Service Asset & Configuration Management is. In this chapter, lets us take a look at the Purpose & Objectives of this process

Purpose of Service Asset and Configuration Management:

The purpose of Service Asset and Configuration Management (SACM) is to:
• Identify and control all items of interest
• Manage and protect the integrity of assets.

Objectives of Service Asset and Configuration Management:

The objective of SACM is to define and control the components of services and infrastructure, and to maintain accurate configuration information on the historical, current and planned states of these components, services and infrastructure.

Scope of Service Asset and Configuration Management:

Asset Management covers service assets across the whole Service Lifecycle. It provides a complete inventory of assets and records who is responsible for their control. It includes full lifecycle management of IT and service assets, from the point of acquisition through maintenance to disposal.

Configuration Management provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and Configuration Items. It ensures that components are identified, baselined and maintained, and that changes to them are controlled. The scope covers interfaces to internal and external service providers where there are assets and Configuration Items that need to be controlled (e.g. shared assets).

SACM optimizes the performance of service assets and configurations and therefore improves the overall performance of the service, and minimizes the costs and risks caused by poorly managed assets (e.g. service outages, fines, incorrect license fees and failed audits).

Prev: Introduction to SACM

Next: More on SACM

Introduction to Service Asset and Configuration Management

Organizations invest huge amounts of money in IT equipment and ancillary resources, which are assets of the organization. Accordingly, we need to maintain information about those assets in terms of their source, value, location, who controls them etc. This is Asset Management.

Configuration Management goes beyond this in providing us with information about the relationships that exist between the various components. This is essential to effective service management solutions since this information underpins all of the other processes particularly Incident, Problem, Availability and Change Management.

When a change is proposed, comprehensive configuration information enables the rapid and accurate assessment of the impact of the change on services and components. Similarly, calls to the Service Desk can be simplified if the agent can automatically see what services and systems the caller uses.

Prev: Key Activities in Request Fulfillment

Next: Purpose & Objectives of SACM

Key Activities in Request Fulfillment

Request Fulfillment should be made as simple as possible. Unlike Incidents, Requests ought to be predictable and planned for. It will depend on the size and scale of an organization whether Requests are handled through the same logging system as Incidents. For organizations with a large number of Requests, a separate logging and progressing system may be appropriate.

The key role of Request Fulfillment is to handle a large number of Requests efficiently and to avoid any bureaucratic bottlenecks. Users will be frustrated if a legitimate Request or query cannot be efficiently handled and responded to. A holistic view of the situation can be taken by handling all the Requests in one place, allowing training needs, communication gaps and requirements for Standard Changes to be identified.

Request Models

Where high volumes of the same or similar requests are expected, a process model can be defined to standardize the activities to be undertaken. Adoption of Request models will streamline the process and allow greater volumes to be processed.

Relationship with Other Service Management Processes

Request Fulfillment is a pretty straightforward and simple process. It does not interact with many of the other service management processes. It interacts with only two of those processes:
1. Financial Management &
2. Change Management

Financial Management

There needs to be a strong link between Financial Management and Request Fulfillment to ensure that volumes, workload and use of resources are fully understood.

Change Management

Where the Request model relates to a Standard Change, there will have been the necessary approval from Change Management which will have taken into account the Financial Management issues.

Prev: Introduction to Request Fulfillment

Next: Introduction to Service Asset and Configuration Management

Introduction to Request Fulfillment

Request Fulfillment is the Process that carries out Service Requests from users. It covers Standard Change requests, requests for information and complaints. From a Service Desk point of view, the process of Request Fulfillment tends to cover all the calls that are not Incidents. Password resets and queries about obtaining additional software are some of the higher volume requests.

Requests are usually high in volume, but low risk and low cost. A separate distinct process is in place to avoid confusion with the Incident handling that the Service Desk is also undertaking.

Before we go any further with Request fulfillment process, we need to understand two key definitions.

Service Request:

A Service Request is a request from a user for information, for advice, for a Standard Change or for access to an IT Service.

Standard Change:

A Standard Change is a pre-approved Change that is low risk, relatively common and follows a Procedure or Work Instruction.

Objective of Request fulfillment:

The objective of the process is to action the Service Requests effectively and efficiently. Request Fulfillment allows Users to obtain information and complete Standard Changes as quickly as possible.

Prev: Service Desk Challenges

Next: Key Activities

Challenges Faced by Service Desk

As explained in the previous chapter, the Service Desk role is extremely crucial to the business’s success and is of high visibility. As a result, there are numerous challenges faced by it.

Challenges facing Service Desks include:
• Recruiting, training and retaining staff with the appropriate skills
• Procuring, utilizing and maximizing the performance of an appropriate Service Desk tool
• Ensuring that the Service Desk is the single point of contact
• Ensuring that the Service Desk is not bypassed
• Obtaining meaningful Customer Satisfaction data

People In-Charge of the Service Desk

There are potentially a number of individuals who collective share responsibility in terms of handling the Service Desk operations. They are:
• Service Desk Manager
• Service Desk Supervisor
• Service Desk Analyst
• Super User

The mix of roles will be determined by the size of the organization being supported and the type of support being provided.

Relationship with Other Service Management Processes

The Service Desk undertakes a number of Service Management processes, primarily Incident Management and Request Fulfillment. There will also be links to many other processes. Service Level Management provides the targets for Incident and Request handling. Change Management will provide details of forthcoming changes allowing the Service Desk to plan, train and roster staff accordingly.

Prev: Service Desk Metrics

Next: Introduction to Request fulfillment

Service Desk Metrics

The Service Desk is one of those functions, where the metrics are of extreme importance. Whenever a service offers a support function, its effectiveness needs to be measured on a regular basis to ensure that customer satisfaction isnt affected.
Metrics should be put in place to measure the performance of the Service Desk. While call volumes are important to indicate required staffing levels, they are not a measure of Service Desk performance or something that the Service Desk can necessarily control.

Some Commonly used Metrics are:
• The average time to resolve an Incident
• The percentage of calls resolved during the first call
• The average time to escalate an Incident
• The average cost of calls

Prev: Key Activities in Service Desk

Next: Challenges in Service Desk

Key Activities in Service Desk

The key activity undertaken by the Service Desk is to manage Incidents and Events as effectively and as efficiently as possible. In order to facilitate this, Service Desk staff needs to have certain skills. It is the application of these skills, along with the use of an appropriate toolset that allows the Service Desk to be effective and efficient.

Skills required by Service Desk staff

Staff should be recruited with the skills listed below. Ongoing training is required to ensure that these skills are being translated into an effective service and to ensure that the quality of that service is consistent. Service Desk staff should be:
• Customer focused
• Business aware
• Service aware
• Technology aware
• Articulate

They should have:
• Good interpersonal skills
• The ability to translate the user description into an Incident narrative.

Training will be needed on:
• The processes used by the Service Desk
• Using the tool and relevant technology
• Problem-solving skills

Prev: More on Service Desk

Next: Service Desk Metrics

More on The Service Desk

In the previous chapter, we learnt what “The Service Desk” is. In this chapter, we are going to learn some of the basic concepts about the same.

Methods of contacting the Service Desk

Traditionally, most IT users have contacted their Service Desk via telephone. However, there are various methods of making contact with a Service Desk:
• Telephone
• Web interface
• Automated alert
• Email
• Pager
• Personal contact.

Single point of contact

It is very important that the Service Desk is the single point of contact for IT users within an organisation. Without a single point of contact, there is no control and ownership throughout the management of Incidents, Service Requests and queries.
It is the Service Desk which owns Incidents throughout their lifecycle. It does not matter who is working on the Incident, the ownership remains with the Service Desk. The Service Desk will receive and log Incidents or Service Request details. They will undertake first-line investigation and diagnosis with escalation if Incidents or Service Requests are not resolved.
The existence of the single point of contact can be reinforced by advertising the sole Service Desk number or email address as widely as possible.

Service Desk structures

The Service Desk can be structured in a number of ways. The structure should be driven by the nature of the business supported. Factors such as user skill profile and geographical location of users will influence the structure.

Service Desk structures can be:
1. Local
2. Centralized
3. Virtual
4. Follow The Sun &
5. Specialized

Let us now take a detailed look at each of them.

Local Service Desk:

Local Service Desks are situated adjacent to the users that they support. Usually in the same city or state and in the same Time-Zone.

The advantages of such a structure are visibility of the Service Desk function and easy communication links. However, there are disadvantages such as the risk of Incidents not being prioritised in line with business impact because users are able to physically appear at the Service Desk and request/demand action. Another potential disadvantage is that Service Desk staff are not used as efficiently as they would be under other Service Desk structures because they are ‘fixed’ in one place supporting local users.

Centralized Service Desk:

Typically, organizations have moved away from Local Service Desks to adopting a centralised Service Desk. Efficiency and cost-effectiveness are the reasons for this. Economies of scale can be exploited by having all of the organisation’s Service Desk staff in one physical location. By adopting a single telephone number, calls from anywhere in the organisation will be directed to the centralized Service Desk. It should not matter to the user where their call is dealt with their only interest ought to be the way in which the call is handled.

Virtual Service Desk:

From the user’s point of view, the response they receive from a virtual Service Desk will be the same as the one they receive from a centralised Service Desk. However, the persons who operate a virtual Service Desk can be in a number of different locations. By utilising a single universal tool, users are able to obtain a service which is the same regardless of their location or the location of the responding Service Desk staff.

One advantage of such a structure is that it allows far greater staff flexibility. Staff may be able to work from home or organisations may be able to be more efficient by using offshore working by some or all of the Service Desk staff. There is, however, a risk that service quality lacks consistency and this is something that needs to be managed via metrics designed to measure the quality of service from the various locations.

Follow the Sun:

Organizations with sites & staff around the world may find it more efficient to switch between two or three Service Desks during a 24-hour period. For example, the Service Desk based in Singapore would take all the incoming calls for eight hours prior to switching to the London Service Desk. London would be the Service Desk through normal European working hours before switching to New York. After another eight hours, New York would switch back to Singapore and so on.
The advantage of this approach is that it makes it possible for Service Desk staff to work a normal shift without the need for overtime and additional payments.

A ‘Follow the Sun’ approach relies on good handovers between the sites. Language can be an issue and it is crucial that information from users is recorded in a central tool in such a way that it is understood wherever it is picked up.

Specialized Service Desk Groups:

Within Service Desks it is possible to put together specialist groups who perhaps look after one particular high profile or complex service. Where this happens, calls can be routed to the specialist group via the telephony with an option being given to the caller to divert to the group.

Prev: Introduction to Service Desk

Next: Key Activities in Service Desk


© 2013 by All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.


Popular Posts