3659122 ITIL Foundations

8/8/2019 3659122 ITIL Foundations

http://slidepdf.com/reader/full/3659122-itil-foundations 1/199



Material do Curso de ITIL

ÍndiceIntroduction ............................................................................................................................ 7IT Service Management........................................................................................................ 10

IT Service Management – Background............................................................................ 10

Services and Quality..................................................................................................... 12

Quality Assurance ........................................................................................................ 14ISO-9000 ...................................................................................................................... 16

Organizational Maturity ............................................................................................... 17

CMM ............................................................................................................................ 18Organization and Policies................................................................................................. 19

Vision, objectives and policies..................................................................................... 19

Planning Horizon.......................................................................................................... 21Culture .......................................................................................................................... 22

Human Resource Management..................................................................................... 23

IT Customer Relationship Management....................................................................... 24

Processes........................................................................................................................... 26Processes and departments ........................................................................................... 27

IT Service Management................................................................................................ 27

Introduction to ITIL.............................................................................................................. 28Background....................................................................................................................... 28

Advantages to the Customer/End User: ....................................................................... 29

Advantages to the IT Organization: ............................................................................. 30Potential disadvantages: ............................................................................................... 30

Organizations................................................................................................................ 31

OGC (CCTA) ............................................................................................................... 31ITSMF .......................................................................................................................... 31

EXIN and ISEB ............................................................................................................ 32The ITIL Books ................................................................................................................ 33

ITIL (IT Infrastructure Library) ................................................................................... 33Business Perspective .................................................................................................... 34

Service Delivery ........................................................................................................... 36

Service Support ............................................................................................................ 38IT Infrastructure Management...................................................................................... 40

Applications Management............................................................................................ 42Management and Organization..................................................................................... 42

Planning and Implementation....................................................................................... 43

Service Desk......................................................................................................................... 45

Introduction ...................................................................................................................... 45Objective........................................................................................................................... 45

Process Description .......................................................................................................... 45Activities........................................................................................................................... 46

Activities....................................................................................................................... 46

Incident control............................................................................................................. 47

Roles................................................................................................................................. 48Relationships .................................................................................................................... 48

- 2 -




Benefits............................................................................................................................. 49Summary....................................................................................................................... 50

Common Problems ........................................................................................................... 51

Metrics.............................................................................................................................. 52Service Desk Structure - Best Practice............................................................................. 53

Structure of a Service Desk .......................................................................................... 53Centralised Service Desk.............................................................................................. 55

Virtual Service Desk..................................................................................................... 55Essential Terms ................................................................................................................ 57

Incident Management ........................................................................................................... 58

Introduction ...................................................................................................................... 58

Objective........................................................................................................................... 58

Process Description .......................................................................................................... 59Activities........................................................................................................................... 60

Incident detection and recording .................................................................................. 60

Classification and initial support.................................................................................. 60Investigation and diagnosis .......................................................................................... 61

Resolution and recovery............................................................................................... 62

Incident closure ............................................................................................................ 62Incident ownership, monitoring, tracking and communication.................................... 62

Roles................................................................................................................................. 62

Relationships .................................................................................................................... 63

Benefits............................................................................................................................. 64Common Problems ........................................................................................................... 65

Metrics.............................................................................................................................. 66

• Number of Incidents per time period.................................................................... 66

• Number of Incidents per category ........................................................................ 66

•

Number of Incidents per priority level ................................................................. 66• Incident resolution performance against service levels........................................ 66

• Number of closed Incidents per time period ........................................................ 66Best practice ..................................................................................................................... 66

Incident Management tools: ......................................................................................... 66

Different types of escalation......................................................................................... 67Essential Terms ................................................................................................................ 68

Problem Management........................................................................................................... 68


Process Description .......................................................................................................... 70

Activities........................................................................................................................... 72Problem Control ........................................................................................................... 72

Error Control ................................................................................................................ 74

Proactive Problem Management................................................................................... 74

Completion of Major Problem reviews ........................................................................ 75Roles................................................................................................................................. 75

Relationships .................................................................................................................... 76

Benefits............................................................................................................................. 77

- 3 -




Common Problems ........................................................................................................... 78Metrics.............................................................................................................................. 79

Best practices.................................................................................................................... 80

Essential Terms ................................................................................................................ 81Introduction ...................................................................................................................... 82

Objective........................................................................................................................... 83Process Description .......................................................................................................... 83

Activities........................................................................................................................... 85Recording ..................................................................................................................... 85Accepting (Rejecting)................................................................................................... 85

Classifying.................................................................................................................... 85

Planning........................................................................................................................ 85

Coordination ................................................................................................................. 86Evaluating..................................................................................................................... 86

Roles................................................................................................................................. 87

Change Manager........................................................................................................... 88Change Advisory Board (CAB) ................................................................................... 88

Change Advisory Board/Emergency Committee (CAB/EC) ....................................... 88

Relationships .................................................................................................................... 88Benefits............................................................................................................................. 90

Common Problems ........................................................................................................... 90

Metrics.............................................................................................................................. 91

Best practices.................................................................................................................... 91Essential Terms ................................................................................................................ 92

Configuration Management.................................................................................................. 93


Process Description .......................................................................................................... 94

Activities........................................................................................................................... 96Planning:....................................................................................................................... 96

Identification: ............................................................................................................... 97

Status accounting.......................................................................................................... 98Verification and audit ................................................................................................... 98

Roles................................................................................................................................. 99

Relationships .................................................................................................................... 99

Benefits........................................................................................................................... 100Common Problems ......................................................................................................... 101

Metrics............................................................................................................................ 102

Key performance indicators ....................................................................................... 102Best practices.................................................................................................................. 103

The CMDB ................................................................................................................. 103

Interesting Websites ................................................................................................... 104Essential Terms .............................................................................................................. 104

Release Management.......................................................................................................... 105

Introduction .................................................................................................................... 105

Objective......................................................................................................................... 106Process Description ........................................................................................................ 107

- 4 -




Activities......................................................................................................................... 108Roles............................................................................................................................... 112

Relationships .................................................................................................................. 113


Metrics............................................................................................................................ 115Best practices.................................................................................................................. 116

Interesting web sites ................................................................................................... 117Essential Terms .............................................................................................................. 118

Introduction ........................................................................................................................ 119

Objective......................................................................................................................... 120

Process Description ........................................................................................................ 121


Benefits........................................................................................................................... 128

Common Problems ......................................................................................................... 130Metrics............................................................................................................................ 132

Best practices.................................................................................................................. 132

Essentials (terminology)................................................................................................. 133Financial Management ....................................................................................................... 134

Introduction .................................................................................................................... 134

Objective......................................................................................................................... 136

Process Description ........................................................................................................ 137Activities......................................................................................................................... 138

Roles............................................................................................................................... 143

Relationships .................................................................................................................. 144Benefits........................................................................................................................... 144

Common Problems ......................................................................................................... 145


Essentials (terminology)................................................................................................. 147

Availability Management ................................................................................................... 149Introduction .................................................................................................................... 149

Objective......................................................................................................................... 149



Relationships .................................................................................................................. 156


Metrics............................................................................................................................ 160

Best practices.................................................................................................................. 160Capacity Management ........................................................................................................ 162

Introduction .................................................................................................................... 162

Objective......................................................................................................................... 163


- 5 -




Relationships .................................................................................................................. 168Benefits........................................................................................................................... 170

Common Problems ......................................................................................................... 171


Essentials (terminology)................................................................................................. 174IT Service Continuity Mgt.................................................................................................. 175

Introduction .................................................................................................................... 175Objective......................................................................................................................... 176Process Description ........................................................................................................ 176

Activities......................................................................................................................... 178

Roles............................................................................................................................... 182

Relationships .................................................................................................................. 183Common Problems ......................................................................................................... 186

Metrics............................................................................................................................ 187

Best practices.................................................................................................................. 187Essentials (terminology)................................................................................................. 188

Security Management......................................................................................................... 190

Introduction .................................................................................................................... 190Objective......................................................................................................................... 191


Activities......................................................................................................................... 193

Roles............................................................................................................................... 194Relationships .................................................................................................................. 194

Benefits........................................................................................................................... 195

Common Problems ......................................................................................................... 196Metrics............................................................................................................................ 196

Best practices.................................................................................................................. 197

Essentials (terminology)................................................................................................. 198Conclusion.......................................................................................................................... 198

Further reading ............................................................................................................... 199

- 6 -




In the 1980s, the quality of the IT services provided to the British governmentlead the CCTA (Central Computer and Telecommunications Agency as it was referred to

- now the Office of Government Commerce, OGC) was instructed to develop anapproach for efficient and financially effective use of IT resources by ministries and

other British public sector organizations. The aim was to develop aframework/methodology/approach that was vendor/supplier independent. This resulted

in the Information Technology Infrastructure Library™ (ITIL). ITIL v1 grew from acollection of best practices observed in the IT service industry.

The ITIL framework provides a detailed description of a number of important IT

practices, with comprehensive checklists, tasks, procedures and responsibilities whichcan be tailored to any IT organization. Where possible, these practices have been

defined as processes covering the major activities of IT service organizations. Thebroad subject area covered by the ITIL publications makes it useful to refer to them

regularly and to use them to set new improvement objectives for the IT organization.

The organization can grow and mature with them.

A number of other IT Service Management frameworks have been developed on thebasis of ITIL, generally by commercial organizations. This is one of the reasons why

ITIL has become the de facto standard for describing a number of fundamentalprocesses in IT Service Management.

Special note: The most widely known "other frameworks" that havebeen based on ITIL is the Microsoft Operations Framework. Microsoft donot try and conceal their proprietary framework has it's basis in ITIL.They in fact praise ITIL as an excellent starting point for organizationswith Microsoft Environments. What Microsoft have done however, isextend ITIL and create a series of other processes and specific concepts.

ITIL is often referred to as Best Practice, although the relatively new term of

"good practice" is starting to be widely used.

Note: The term "best practice" will often spark heated debate amongsome IT professionals. If you are not certain then the term "goodpractice" may be a safer option to use. The ITIL material claims that it isBest Practice.

The broader adoption of ITIL has been hampered by the lack of a basic, but

effective introductory textbook. This course is the electronic version of this missingtext. The course is beneficial for anyone involved in IT Service Management.

- 8 -




IT Service Management

I T Se rv i ce M anagem en t – Backg r ound

In this section we will look at services, quality, organization, policy and process

management. All these topics provide the background for the development of a

systematic approach to IT Service Management.

The IT Service Management processes described in this course (also referred to

as IT Management) are best understood against the background of the concepts aboutorganizations, quality and services which influenced the development of the discipline.Familiarity with these terms also helps to understand the links between the various

elements of the IT Infrastructure Library (ITIL). ITIL is by far the best knowndescription of IT Service Management and is therefore used as the foundation for this

Course.

The Objective Tree

The objective tree is used to help all members of the organization understandthe benefits of ITSM. Starting at the top of the tree, the most important consideration

for any business is that the Organization's Objectives are met (eg. Increased market

share, lower costs and higher customer satisfaction).

Failure to meet the overall objectives means that the organization ceases to

function (no matter how well the IT department is run). In order for the organization's

objectives to be met, there must be a series of business departments working togetherin Business Processes. An example of a business process is the "enrollment process" in

a University. The "enrollment process" involves Admissions (to capture basic studentdetails), Security (to issue id-card), Library (to provide required book lists), etc.

Each of these business processes needs a variety of services (IT Service

Provision in our Objective Tree) in order to work. In our University example theAdmissions department has a Student system, Security has it's Security system and

the Library has a Library system (hopefully all share a common repository of student

information, but they all exist for a different reason).

The next branch of the Objective Tree is Service Management. It is at this layer

that IT professionals must consider how they need to manage all the infrastructure(including hardware, software, tools, etc.) in order to make the required Services

available, to the Business Processes so that the Organization Objectives can be met.

Getting this right earns everyone a medal!

- 10 -




This chapter introduces the following subjects:

• The section on the provision of services and quality addresses the

relationship between the quality experienced by the customer's

organizational end users, and quality management by the provider of the ITservices.

• The section on organization and policies addresses concepts such as vision,

objectives, and policies and discusses issues such as planning, corporateculture and Human Resource Management. This section also discusses the

coordination between the business processes of a company and the IT

activities.

• The section on process management looks at the control of IT serviceprocesses.

- 11 -




Services and Quality

Organizations are often highly dependent on their IT services and expect the ITservices not only to support the organization, but also to present new options to

achieve the objectives of the organization. Furthermore, the high expectations of customers on IT Services tend to change significantly over time (usually in a

downgrading of expectations).

Providers of IT services can no longer afford to focus on technology. They nowhave to consider the quality of the services they provide and focus on the relationship

with their customers.

The provision of IT services refers to the f u l l management of the ITinfrastructure. Hardware, software, tools and relationships.

Before buying a product in a shop, we normally assess the quality such as

the appearance, usefulness for the task and robustness. In a shop, the customer hasfew opportunities to influence the product quality. This is because the product is

produced in a factory. By effectively controlling the production plant, the manufacturerwill try to deliver a fairly constant quality. In this example, manufacture, sales and

consumption of the product are quite separate.

However, services are provided through interaction with the customer.Services cannot be assessed in advance, but only when they are provided. The quality

of a service depends to some extent on the way in which the service provider and thecustomer interact. In contrast to the manufacturing process, customer and provider

can still makes changes when the services are being delivered. How the customer

perceives the service and what the provider thinks they supply, both depend largely ontheir personal experiences and expectations.

The process of providing a service is a combination of production and use, inwhich the provider and customer participate simultaneously.

The perception of the customer is essential in the provision of services.

Customers will generally use the following questions to assess the quality of theservice:

• Does the service align with my expectations?

• Can I expect a similar service the next time?

• Is the service provided at a reasonable cost?

Whether or not the service fulfils the expectations depends primarily on how

effectively the deliverables were agreed on in the first place, even more so than onhow well the supplier provides the service.

A continuing dialogue with the customer is essential to refine the services

and to ensure that both the customer and the supplier know what is expected of theservice. In a restaurant, the waiter will first explain the menu, and ask if everything is

all right when serving a new course.

- 12 -




The waiter actively coordinates supply and demand throughout the meal. Thisexperience with customers is then used to improve future customer contact.

The quality of a service refers to the extent to which the service fulfils therequirements and expectations of the customer. To be able to provide quality, the

supplier should continuously assess how the service is perceived and what the

customer expects in the future.

Another customer may well consider what one customer considers normal as a

special requirement.

Eventually a customer will get used to something considered special at the

start. The results of the assessment can be used to determine if the service should bemodified, if the customer should be provided with more information, or if the price

should be changed.

Quality is the totality of characteristics of a product or service that bear on itsability to satisfy stated and implied needs (ISO-8402).

Reasonable costs may be considered as a derived requirement. Once it has been

agreed on what is to be expected of the service, the next step is to agree on what itmay cost. At this stage the service provider has to be aware of the costs they incur,

and the current market rates for comparable services.

A customer will be dissatisfied about a service provider who occasionallyexceeds the expectations but disappoints at other times. Providing a constant qualityis one of the most important, but also one of the most difficult aspects of the serviceindustry.

For example, a restaurant will have to purchase fresh ingredients, the chefs will

have to work together to provide consistent results, and hopefully there are no majordifferences in style among the waiting staff. A restaurant will only be awarded three

Michelin Stars when it manages to provide the same high quality over an extendedperiod. This does not often happen: there are changes among the waiting staff, a

successful approach may not last, and chefs leave to open their own restaurants.

Providing a constant high quality also means that the component activities have to becoordinated: the more efficiently the kitchen operates, the more quickly the guests can

be served.

Therefore, when providing a service, the overall quality is the result of the

quality of a number of component processes that together form the overall service.These component processes formed a chain; a series of linked activities. Effective

coordination of the component processes requires not only high quality at each stage,

but also consistent quality.

- 13 -




Quality Assurance

Supplying products or services requires activities. The quality of the product orservice depends largely on the way in which these activities are organized. Deming’s

quality life cycle provides a simple and effective model to address quality. The modelassumes that to provide appropriate quality, the following steps must be undertaken

repeatedly:

• Plan: Who should do what, when, how, using what?

• Do: Implementation of the planned activities.

• Check: Determine if the activities provided the expected result.

• Act: Adjust the plans based on information gathered while checking.

To be able to make use of this life-cycle approach, the activities of supplying productsand services must be divided into processes, each with their own plans and

opportunities for conducting checks. It must be clear who is responsible in theorganization and what authority they have to change plans and procedures, not for

only for each of the activities, but also for each of the processes.

Quality management is the responsibility of everyone working in the organizationproviding the service. Every employee has to be aware of how their contribution to the

organization affects the quality of the work provided by their colleagues, andeventually the services provided by the organization as a whole. Quality management

also means continuously looking for opportunities to improve the organization andimplementing quality improvement activities.

Quality assurance is a policy matter within the organization. It is the whole of the

measures and procedures, which the organization uses to ensure that the services

- 14 -




provided, continue to fulfill the expectations of the customer and the relevantagreements. Quality assurance ensures that improvements resulting from quality

management are maintained.

A quality system is the organizational structure related to responsibilities, procedures

and resources for implementing quality management.

The ISO 9000 series of standards is often used to develop, define, assess and improve

quality systems.

Dr. Edward Deming was an American statistician brought to Japan by generalDouglas MacArthur after the Second World War to help rebuild the destroyed economy.He had developed theories about the best possible use of expertise and creativity inorganizations in the United States in the 1930s, but because of the Depression hisideas were not accepted in the US. However, his optimization methods weresuccessfully adopted in Japan.

Some of Deming’s typical statements:

• ‘The customer is the most important part of the production line.’ • ‘It is not enough to have satisfied customers, the profit comes from returning

customers and those who praise your product or service to friends andacquaintances.’

• ‘The key to quality is to reduce variance.’ • ‘Break down barriers between departments.’ • ‘Managers should learn to take responsibility and provide leadership’ • ‘Improve constantly.’ • ‘Institute a vigorous program of education and self-improvement.’ • ‘Institute training on the job.’ • ‘The transformation is everybody's job.’

- 15 -




ISO-9000

Some organizations require their suppliers to hold an ISO 9001 or ISO 9002certificate. Such a certificate proves that the supplier has an adequate quality system

whose effectiveness is regularly assessed by an independent auditor.

ISO is the International Standards Organization. A quality system that complies

with the ISO standard testifies that the supplier has taken measures to be able toprovide the quality required by their customers;

• the management regularly assesses the operation of the quality system, and

uses the results of internal audits to implement improvement measures wherenecessary;

• the suppliers’ procedures are documented and communicated to those affectedby them;

• customer complaints are recorded, dealt with in a reasonable time, and used to

improve the service where possible;• the supplier controls the production processes and can improve them.

An ISO certificate does not provide an absolute guarantee about the quality of the service provided, however, it does indicate that the supplier takes quality

assurance seriously and is prepared to discuss it.

The new ISO 9000 series of standards, ISO-9000-2000, puts even greateremphasis than the previous standard on the ability of an organization to learn from

experience and to implement continuous quality improvement.

- 16 -




Organizational Maturity

Experience with improving the quality of IT services has shown that it is rarelysufficient to simply define current practices. The causes of a mismatch between the

service provided and the customer’s requirements are often related to the way inwhich the IT organization is managed. A permanent quality improvement focus

demands a certain degree of maturity of the organization.

The European Foundation for Quality Management (EFQM) model can be usefulin determining the maturity of an organization. It identifies the major areas to be

considered when managing an organization.

Deming’s Quality Life-Cycle is incorporated in the EFQM model. Based on theoutcomes from "result areas" actions are taken (strategy, policies). These actions

serve to underpin the planning (e.g. the structure of the processes), that should leadto the desired results. The EFQM identifies nine areas.

In 1988 fourteen large European companies, with the support of the EuropeanCommission, set up the European Foundation for Quality Management.

The objective of the EFQM is to promote Total Quality Management, aimed atexcelling in customer satisfaction, employee satisfaction and appreciation by society,and performance results.

The EFQM ‘Model of Business Excellence’, generally known simply as the EFQMmodel, is widely accepted as the major strategic framework for managing anorganization aimed at the balanced, continuing improvement of all aspects relevant tothe business.

- 17 -




Organization and Policies

We know that service quality is closely associated with the quality of an

organization and its policies.

This section will discuss several important aspects of the organization andpolicies that are relevant to process management.

Vision, objectives and policies

An organization is a form of cooperation between people. Any organization,

from a darts club to a multinational company, depends on a concept of why it is worthcooperating in the organization. The shared vision might be that you can make money

selling or you can improve the environment. However, to be attractive to allstakeholders (e.g. customers, investors, personnel) as an organization it has to be

communicated to clients why they should do business with you. For example because

you are the best, cheapest or most fun. You will want to build up a suitable image.Think of the things that stick in your mind – “Just Do It” (Nike).

To communicate the vision, the organization creates a Mission Statement.The mission statement is a short, clear description of the objectives of the

organization and the values it believes in.

The objectives of the organization describe in greater detail what it wants toaccomplish. Good objectives have five essential elements: they have to be Specific,

Measurable, Appropriate, Realistic and Time-bound (SMART).

The policy of the organization is the combination of all decisions and measures

taken to define and realize the objectives. In its policies, the organization will prioritize

objectives and decide how the objectives will be reached. Of course, priorities maychange over time, depending on the circumstances. The clearer the organization’s

policies are to all stakeholders, the less needs to be defined about how personnel aresupposed to do their work. Instead of detailed procedures, personnel can

independently use the policies as their guideline. Clearly formulated policies contributeto a flexible organization, as all levels in the organization can respond more quickly to

changing circumstances.

Implementing policies in the form of specific activities requires planning. Plansare usually divided into stages to provide milestones where progress can be monitored.

For example, the policies can be used to draw up an annual plan, which is then used to

- 19 -




develop the budgets. An organizational annual plan can be further developed intogreater detail as departmental plans, quarterly plans or project plans. Each of these

plans contains a number of elements: an activity schedule, the required resources, andagreements about the quality and quantity of the products or services to be delivered.

Realization of the planned activities requires action. Actions are allocated to

personnel as tasks, or outsourced to external organizations.

When translating the mission of the organization into objectives, policies,

planning and tasks, there is the risk that after some time, the mission, objectives orpolicies are forgotten. It is therefore important that at every stage we measure if the

organization is still moving in the right direction, and remedial action is taken wherenecessary.

We have to measure if the organization or processes fulfill the objectives, andthere are various methods available for this. One of the most common methods in

business is the Balanced Score Card, or BSC. In this method, the objectives of the

organization or process are used to define Critical Success Factors (CSF). CSFs are

defined for a number of areas of interest or perspectives: customers/market, businessprocesses, personnel/innovation and finance. The parameters used to measure if theCSFs meet the standards are known as Key Performance Indicators (KPI). Where

necessary, these can be subdivided into Performance Indicators (PI).

Key performance indicators, or KPIs, are parameters for measuring progressrelative to key objectives or Critical Success Factors (CSF) in the organization.

The outcome of the measurements and changing circumstances can lead to

modification of the processes, tasks, plans, and policies, and even to a change in theobjectives, mission and vision of the organization. The more mature an organization is,

the better it deals with such changes.

If the IT department supports the interests of the business, the objectives of the IT department will be derived from the business objectives. The IT department, for

example, might have the following objective: ‘To contribute to the competitive strengthof the business’. The specific objectives of the IT department will then be developed on

the basis of this general objective.

Depending on the nature of the business, objectives will be defined for the ITdepartment with respect to safety, accessibility, response speed, technical

sophistication and so on.

- 20 -




Planning Horizon

When considering the policies and planning of an IT department, we should be

aware of the links between planning for the business as a whole and the applicationsystems and the technical infrastructure used by the business. When planning the

network and applications of a business, the IT department will have to stay ahead of the overall planning to ensure that the business has an IT infrastructure in which it can

develop and grow into. The figure below gives an example of the links between thevarious plans.

Technical infrastructure has the longest planning horizon and in itssupport role it has fewer clear links with the substantive business activities. It takestime to develop a technical infrastructure and the fact that information systems and

the business depend on the technical infrastructure, limits the speed at which changescan be implemented. Furthermore, developing a technical infrastructure demands

significant investment and the period over which it can be depreciated has to beconsidered.

- 21 -




The planning horizon is shorter for applications as they are designed for specific

business purposes. Application life cycle planning is primarily based on the business

functions to be provided by the system, after which the underlying technology isconsidered.

Business plans, based on the organization’s strategy, normally cover one calendar

or financial year. Budgets, planning and progress reports all fall within this period. Insome markets, the planning cycle time has become even shorter as the cycle time for

product development has also decreased.

Planning should address four elements:

• Time - this is the easiest factor to determine. It is defined by a starting date andending date, and is often divided into stages.

• Quantity - the objectives have to be made measurable to monitor progress. Terms

such as ‘improved’ and ‘quicker’ are insufficient for planning purposes.

• Quality - the quality of the deliverables (results) should be appropriate for theobjective.

• Costs and revenues - the deliverables must be in proportion to the expected costs,efforts and revenues.

Differences between the planning horizons occur not only between areas, but

also between the various levels of activities and processes (strategic, tactic andoperational).

Culture

Organizations that want to change (for example to improve the quality of their

services) will eventually be confronted with the current organizational culture. The

organizational culture, or corporate culture, refers to the way in which people deal witheach other in the organization; the way in which decisions are made and implemented;

and the attitude of employees to their work, customers, suppliers, superiors andcolleagues.

Culture, which depends on the standards and values of the people in theorganization, cannot be changed, but it can be influenced. Influencing the culture of an

organization requires leadership in the form of a clear and consistent policies and a

supportive personnel policy.

The corporate culture can have a major influence on the provision of IT

services. This is due to the fact that businesses value innovation in different ways. In astable organization, where the culture places little value on innovation, it will be

difficult to adjust the IT services in line with changes in the organization. If the IT

department is unstable, then a culture that values change can pose a serious threat tothe quality of its services. In that case, a free for all can develop where many

uncontrolled changes lead to a large number of faults.

- 22 -




Human Resource Management

Personnel policy plays an important and strategic role in fulfilling the long-termobjectives of an organization (see also the EFQM model). It can also be used as an

instrument to change the corporate culture. The objective of modern personnel

management is to optimize the performance of all personnel in the organization. Avariety of instruments such as recruitment and selection, training and career

development, motivation and reward are used.

Human Resource Management (HRM) is the major form of modern personnel

management.

Human Resource Management is based on two premises:

• Personnel management should contribute to the objectives of the organization. If

organizations have to respond better and more quickly in an environment which

changes ever more quickly, then this will affect the deployment, quality and number of personnel.

• Giving employees in the organization the opportunity to develop and use their skillswill benefit the organization.

There are three approaches to HRM:

• The hard approach sees human resources as means of production, which have to

be organized as effectively and efficiently as possible. As the corporate strategy isdetermined by economic, technical and market factors, the same applies to personnel

policy. This approach places different values on employees. Some core employees are

strategically more important than peripheral employees who are easily replaceable. Forexample, a company might choose to permanently employ only core personnel, and forthe rest use a pool of flexible personnel.

• The soft approach emphasises that making the best possible use of human

potential and opportunities will benefit the business. Modern employees are highlyeducated, ambitious and prepared to invest a lot in their work. For this reason, their

potential must be identified early and developed continuously (career development,training policy). When selecting its strategy and policy, the business must base its

choices on the talent and potential of its employees.

• The integrated approach looks at the shared interests of personnel and

management in an organization. To reach the objectives of the organization there willhave to be good inflow, movement and outflow of personnel. Changes in the marketand the organization (e.g. developments in technology) lead to constant changes in

the need for skills.

All aspects of personnel policy have to be carefully coordinated. The movement

of employees in the organization, determining and developing skills (competence) andpromoting mobility in the internal labor market is becoming increasingly important in

organizations.

- 23 -




The quality of service provided by an organization benefits if the best use is madeof the potential of its employees. This facilitates continuous improvement. Instruments

for quality management in personnel policy include:

• Policy Deployment - communicating to each employee how and to what extent

their task contributes to realizing the objectives of the organization. An important

condition for the success of policy deployment is that it also extends to all layers of management.

• Empowerment - giving employees the opportunity to organize and implement theirtask in consultation with the organization. The degree of empowerment determines the

extent to which employees can be held responsible for the quality of the work theyprovide.

• Accountability - which may be the result of policy deployment and empowerment.If an employee has had an explanation of what is expected of them, and if they have

had the opportunity to arrange and implement the task as they wanted, then they can

be held accountable for it.

This could be used as a basis for assessing and rewarding employees. The

reward may be material (salary) or immaterial, for example appreciation, newopportunities for development and career opportunities.

• Competence Management - this is both a method to use the competency available

in an organization as effectively as possible, and as a way to systematically developthe competence the organization needs. This approach charts the competence required

by the processes and projects as well as the competence of the employees. When

organizing employees, the focus is not only on obtaining a good match between therequired and available competence, but also on the opportunities to develop

competence, transfer expertise, and learn skills. Mentors or coaches may supportemployees. Setting up skills groups can also support the exchange of experience and

encourage the development of new competence.

IT Customer Relationship Management

The quality of IT services largely depends on good relationships with the

customers of the IT organization. These relationships provide the basis for making andupdating agreements. IT Customer Relationship Management addresses maintaining a

relationship with customers and coordinating with customer organizations, at thestrategic, tactic and operational levels.

In IT Customer Relationship Management, the major challenge is to ensure that

there are good and effective relationships between the IT organization and thecustomer organization at all levels. However, the extent of IT Customer Relationship

Management will be different at each level. One of the elements in customerrelationships is the Service Desk, and the control of the Service Levels can be based on

Service Level Management. In these areas, IT Customer Relationship Management willprimarily play a supportive role, for example, by organizing surveys among customers

and users, providing information, and so forth.

- 24 -




The user is the person behind the PC, the employee who uses IT services fortheir routine activities.

The cus tomer is the person who is authorized to conclude an agreement withthe IT organization about the provision of IT services (for example a Service LevelAgreement, SLA) and who is responsible for ensuring that the IT services are paid for.

IT Customer Relationship Management plays an important role in developing

the Strategic Alignment between the IT organization and the organization purchasing

the IT services. In practice, this is primarily a matter of staying in touch with thecustomer organization, and exploring the options for linking the strategic objectives of

both organizations. This can provide the basis for a long-term relationship, in whichthe IT organization focuses on the customer and proposes IT solutions that the help

the customer reach their business objectives.

Given the dynamic nature of both the customer organization and the IT

organization, the rate of change in both organizations should also be coordinated.

The agreements with the customer about the services to be provided are thendeveloped into service level proposals through Service Level Management. For

example, if the customer wants to introduce an intranet, then the availability, usersupport, implementation of change requests and cost all have to be agreed. These

agreements are laid down in a Service Level Agreement (SLA).

If the customer organization wants changes (expansion or modification) to theIT services that fall within the agreements laid down in the SLA, then a Request forChange will be submitted. Change Management then processes the request.

Changes outside the current agreements are introduced into the Service LevelManagement process.

In most cases, users can contact a Service Desk for operational requests andquestions, and to report problems.

Coordination at a strategic level has a planning horizon of several years. Service

Level Management concerns agreements at the tactical level, with a planning horizonof approximately one year. Change Management, Service Desk and Incident

Management all concern the operational level, with a planning horizon of months or

even weeks.

- 25 -




Processes

When arranging activities into processes, we do not use the existing allocation

of tasks, or any existing departmental (functional) divisions. This is a conscious choice.By opting for a process structure, we can often show that the certain activities in theorganization are uncoordinated, duplicated, neglected, or unnecessary.

A process is a logically related series of activities for the benefit of a definedobjective.

Instead, we look at the objective of each process and its relationships with

other processes. A process is a series of activities carried out to convert an input intoan output. We can label the input and output of each of the processes with qualitycharacteristics and standards (that is, what is expected to go into and what isexpected to come out of the particular process). These characteristics and standards

provide information about the results expected of the process. We end up with linked

chains of processes, which show what goes into the organization and what the resultis. As well as this we can describe monitoring points in the chains to assess the quality

of the products and services provided by the organization.

The standards for the output of each process have to be defined so that the

complete chain of processes meets the corporate objective/s, if each process complieswith its process standard. If the result of a process meets the defined standard, then

the process can be said to be effective. If the activities in the process are also carried

out with the minimum required effort and cost, then the process can be called

efficient. The aim of process management is to use planning and control to ensure

that all processes are effective and efficient.

We can study each process separately to optimize its performance. Theprocess owner is responsible for the process results. The process manager is

responsible for the realization and structure of the process, and reports to the processowner. The process operatives are responsible for defined activities, and report to

the process manager.

The logical combination of activities results in clear points where the quality of processes can be monitored. In a restaurant for example, we can separate

responsibility for purchasing and cooking; chefs may not have the authority topurchase anything as experience may show that they tend to spend too much on fresh

ingredients that do not add value.

The management of the organization can exercise control on the basis of the quality of the process as demonstrated by data from the results of each process. In most cases,

the relevant performance indicators and standards will already be agreed. The day-to-day control of the process can then be left to the process manager. The process

owner will assess the results based on a report of performance indicators and whether

they meet the agreed standard.

- 26 -




Without clear indicators, it would be difficult for a process owner to determinewhether the process is under control, and if planned improvements are being

implemented.

Processes are often described using procedures and work instructions.

A procedure is a description of logically related activities, and who they arecarried out by. A procedure may include stages from different processes. A proceduredefines who does what, and varies depending on the organization.

A set of w o r k i n s t r u ct i o n s defines how one or more activities in a procedureshould be carried out.

Processes and departments

Most businesses are organized in a hierarchy. They have departments, which areresponsible for a group of employees. There are various ways of structuring

departments, for example by customer, product, region or discipline. IT services

generally depend on several departments, customers or disciplines. In a hierarchicalorganization if there is an IT service to provide users with access to an accountingprogram on a central computer it will generally involve several departments.

In this example, the computer centre has to make the program and database

accessible, the data and telecommunications department has to make the computercentre accessible, and the PC support department has to provide users with an

interface to access the application.

Processes that span several departments can monitor the quality of a service bymonitoring certain aspects of quality, such as availability, capacity, cost and stability. A

service organization will then try to match these quality aspects with the customer’s

demands. The structure of such processes can ensure that good data is available aboutthe provision of services, so that the planning and control can be improved.

IT Service Management

IT Service Management is primarily known as the process and service-focused

approach of what was initially known as IT Management. In this chapter we haveexplained that processes should always have a defined objective. The objective of IT

Service Management processes is to contribute to the quality of the IT services. Qualitymanagement and process control form part of the organization and its policies.

In a process-focused approach we also have to consider the situation within anorganization (policies, culture, size, etc.).

ITIL, the best known approach to IT Service Management, does not dictatehow an organization should be structured. ITIL cleverly describes the relationships

between the activities in processes, which are relevant to any organization. ITIL also

provides a framework that allows experiences to be shared in different organizations,as it is a common language.

- 27 -




Introduction to ITIL

This chapter describes the structure and objectives of the IT InfrastructureLibrary (ITIL) and the organizations that contribute to maintaining ITIL as the best

practice standard for IT Service Management.

Background

ITIL was developed due to the fact that a growing number of organizations are

becoming increasingly dependent on IT to help fulfill their corporate objectives. Thisincreasing dependence has resulted in a growing need for IT services of a quality

corresponding to the objectives of the organization, and which meet the requirementsand expectations of the customer. Over the years, the emphasis has shifted from the

development of IT applications to the management of IT services. An IT application(sometimes referred to as an information system) only contributes to realising

corporate objectives if the system is available to users and, in the event of fault ornecessary modifications; it is supported by maintenance and operations.

In the overall life cycle of IT products, the operations phase expenditure

amounts to about 70 to 80% of the overall time and cost, the rest is spent on productdevelopment (or procurement). Effective and efficient IT Service Management are

essential to the success of IT applications.

This applies to any type of organization, large or small, public or private, with

centralised or decentralised IT services, with internal or outsourced IT services. In all

cases, the service has to be reliable, consistent, of a high quality, and at an acceptablecost.

IT Service Management addresses the provision and support of IT servicestailored to the needs of the organization. ITIL was developed to disseminate IT Service

Management best practices systematically and cohesively. The approach is based onservice quality and developing effective and efficient processes.

ITIL offers a common framework for all the activities of the IT department, as

part of the provision of services, based on the IT infrastructure. These activities aredivided into processes, which provide an effective framework for further enhancement

of IT Service Management. Each of these processes covers one or more tasks of the IT

- 28 -




department, such as service development, infrastructure management, and supplyingand supporting the services.

This process approach makes it possible to describe the IT Service Managementbest practices independently from the actual organizational structure of the

department.

Many of these best practices are clearly identifiable and are indeed used, to

some extent, in most IT organizations. ITIL presents these best practices coherently.

The ITIL books describe how these processes (which have sometimes already beenidentified) can be optimized, and how the coordination between them can be improved.

The books also explain how the processes can be formalized within an organization.They provide a frame of reference within the organization for the relevant terminology,

and help to define the objectives and to determine the required effort.

By using a process approach, ITIL primarily describes what must be included in

IT Service Management to provide IT services of the required quality. The structure

and allocation of tasks and responsibilities between functions and departments

depends on the type of organization, and these structures often change. Thedescription of the process structure can help maintain the quality of IT services duringand after reorganizations.

The list below identifies some advantages and disadvantages of ITIL. It does

not claim to be a definitive list. Any attempt to supplement it often leads to aninteresting discussion about the advantages of disadvantages of ITIL and about the

way in which organizations actually use ITIL.

Advantages to the Customer/ End User:

• The provision of IT services becomes more customer-focused and agreements about

service quality improve the relationship.

• The services are better described, and in greater detail.

• The quality and cost of the services are managed better.

• Communication with the IT organization is improved by agreeing on the points of

contact.

- 29 -




Advantages to the IT Organization:

• The IT organization develops a clearer structure, becomes more efficient, and more

focused on the corporate objectives.

• The management is more in control and changes become easier to manage.

• An effective process structure provides a framework for the effective outsourcing of

elements of the IT services.

• Following the ITIL best practices encourages a cultural change towards providing

service, and supports the introduction of a quality management system based on theISO-9000 series.

• ITIL provides a uniform frame of reference for internal communication,

standardisation and identification of procedures.

Potential disadvantages:

• The introduction can take a long time and significant effort, and requires a change of

culture in the organization. An over ambitious introduction can lead to frustrationbecause objectives are never met.

• If process structures become an objective in themselves, the service quality may be

adversely affected. In that case, procedures become bureaucratic (obstacles that are

avoided where possible).

• There is no improvement due a lack of understanding about what processes should

provide, what the performance indicators are, and how processes can be controlled.

• Improvement in the provision of services and cost reductions are not visible.

• A successful implementation requires the involvement and commitment of personnel

at all levels in the organization. Leaving the development of the process structures to a

- 30 -




specialist department may isolate that department in the organization and it may set adirection that is not accepted by other departments.

• If there is insufficient investment in support tools, the processes will not be done justice and the service will not be improved. Additional resources and personnel may

be needed if the organization is already overloaded by routine IT Service Management

activities.

ITIL was obviously developed to capitalize on the advantages. It is appropriate

to recognize and acknowledged that there can be problems with an adoption of ITILpractices. However, the ITIL Framework itself provides a lot of suggestions on

recognizing and therefore preventing such problems, or how to solve them should theyoccur.

Organizations

OGC (CCTA)

ITIL was originally a CCTA product. CCTA was the Central Computer andTelecommunications Agency of the British government. On the 1st April 2001, the

CCTA was amalgamated with the OGC (Office of Government Commerce), which is now

the new "owner" of ITIL. The objective of the OGC is to help its customers in theBritish public sector update their procurement activities and improve their services by

making the best possible use of IT and other instruments. ‘OGC aims to modernizeprocurement in government, and deliver substantial value for money improvements.’

The OGC promotes the use of ‘best practices’ in many areas (e.g. project

management, procurement and IT Service Management). The OGC publishes severalseries (libraries) of books written by British and international experts from a range of companies and organizations.

Library consists of a number of clear and thorough ‘Codes of Practice’ to

promote and provide efficient and effective IT services.

ITSMF

The Information Technology Service Management Forum (ITSMF), originallyknown as the Information Technology Infrastructure Management Forum (ITIMF), was

set up in the UK in 1991. The Dutch ITSMF (ITSMF Netherlands) was the next chapter,set up in November 1993. In 2001 it had over 500 members organizations, both

suppliers and user groups. There are now ITSMF chapters in countries such as SouthAfrica, Belgium, Germany, Austria, Switzerland, the United States, and Australia, who

participate in the ITSMF International group.

- 31 -




The ITIL community also allows for organizations involved to provide feedbackso that the reality of current best practice is quickly reflected and incorporated into the

ITIL theory.

Furthermore, extensions and alternatives have been developed, some of which

may be considered as IT Service Management methods in their own right. These

alternatives often address the needs of certain groups or organizations whose specificproblems are not adequately covered by ITIL.

The unique aspect of ITIL is that it offers a generic framework based on the practicalexperience of a global infrastructure of professional users.

The ITIL Books

ITI L (IT Infrastructure Library)

ITIL is a series of books. As the name suggests it is a Library (IT Infrastructure

Library). This section will describe the various components of the library.

Each of the ITIL books addresses part of the overall ITIL framework. For the

ITIL purist we acknowledge that ITIL is a library of many books. This course is centredon the Service Delivery and Service Support books. We use ITIL as the description of

these two books throughout the course.

ITIL defines the objectives and activities, and input and output of each of the

processes found in an IT organization. However, ITIL does not give a specific

description of how these activities should be implemented, as this will be different inevery organization. The emphasis is on an approach that has been proven in practice,

but (depending on the circumstances) may be implemented in a number of ways. ITILis not a method, instead it offers a framework for planning the most common

processes, roles and activities, indicating the links between them and what lines of communication are necessary.

ITIL is based on the need to supply high-quality services, with an emphasis on

customer service and relationships. The IT organization has to fulfill "customer"requirements, which means maintaining good relationships with them and associated

partners such as suppliers.

Part of the ITIL philosophy is based on quality systems, such the ISO-9000series, and Total Quality frameworks, such as that of the EFQM. ITIL supports such

quality systems with a clear description of the processes and best practices in ITService Management. This can significantly reduce the time required to obtain ISO

certification.

Originally, ITIL consisted of a large number of sets of books, each of whichdescribed a specific area of the maintenance and operation of IT infrastructure. Ten

books describing Service Support and Service Delivery were considered as the core of

- 33 -




ITIL. There were approximately 40 other books on complementary subjects related toIT Service Management, from cabling to managing customer relationships. However,

the original series of books in the Infrastructure Library mostly approached IT ServiceManagement from the IT perspective.

The Business Perspective Set was introduced to bridge the divide between the

business and the IT organization. Even so, certain aspects of ITIL still had a slightlydated approach.

The "core" ITIL books have now been revised and published as two books, oneon Service Support, and one on Service Delivery. This has eliminated significant

overlap and occasional inconsistencies in the earlier series and has improved cohesion.They also support the vision of IT Service Management more thoroughly.

The ITIL puzzle shows the main elements addressed by the ITIL books. Each of these elements interfaces with the others, and overlaps them to some extent.

The elements are:

· The Business Perspective

· Service Delivery

· Service Support

· ICT Infrastructure Management

· Applications Management

. Planning to Implement Service Management

In this chapter, we will introduce the ITIL series of publications using the main

elements of the ITIL puzzle. By the end of 2002 the original set of books, each on aspecific aspect of IT Service Management, should have been replaced by six new ITIL

books, as have the books on Service Support and Service Delivery. However, many of

the best practices to be described in the new books are also included in the currentITIL series. For more information www.itil.co.uk

Business P erspective

The ITIL books in the Business Perspective Set describe many issues related to

understanding and appreciating IT services as an integrated aspect of managing abusiness.

The Business Perspective Set, and the Business Perspective book, which will

eventually replace the set, addresses:

- 34 -

http://www.itil.co.uk/

http://www.itil.co.uk/




• Business Continuity Management

• Partnerships and outsourcing

• Surviving changes

• Adapting the business to radical changes

Other ITIL books address some of these topics, in addition to those in the

Business Perspective Set.

Managing Facilities Management

"Managing Facilities Management" addresses the management of contracts betweenthe IT organization and Facilities Management companies. The Facilities Management

suppliers may be responsible for the operation of all or part of the IT infrastructure.However, the IT organization bears the ultimate responsibility for the services provided

to the customer. This book describes what measures the IT organization can take to

accept responsibility for agreements about Service Levels and how to monitor theservices provided by the facilities suppliers.

Managing Supplier Relationships

To some extent, "Managing Supplier Relationships" is similar to Customer Relationship

Management, but now covering the relationship between the IT organization and itssuppliers. A good relationship with suppliers is not just a matter of contractual

agreements and contacts. The primary concerns are business like forms of cooperationthat contribute to the current and future provision of IT services and fulfilling the

objectives of the IT organization.

Relationships with suppliers can be characterised by the nature and content of thecontacts. These may be to discuss the long-term prospects of existing relationships, to

promote communication, or to investigate the range offered by various suppliers.

The major tasks of the Managing Supplier Relationships process include selecting

suppliers, assessing the performance of suppliers, and determining the way in whichthe IT organization handles supplier contracts.

- 35 -




Service Delivery

As indicated above, Service Support and Service Delivery are considered to be

at the heart of the ITIL framework for IT Service Management. The ITIL book onService Delivery describes the services the customer needs, and what is needed to

provide these services.

The following subjects are addressed:

• Service Level Management

• Financial Management for IT Services

• Capacity Management

• Availability Management

• IT Service Continuity Management

• Security Management (with reference to the ITIL book on Security Management)

There is continual reference to how these areas also integrate the essentialelement of Client Relationship Management.

The complex interrelationship between the processes described in the books onService Support and Service Delivery is almost impossible to show in a diagram. We

will briefly describe each of these areas now:

IT Customer Relationship Management

Most organizations appreciate the need to apply cohesion and structure to

relationships within the customer organization at several levels. The IT CustomerRelationship Management activities involve several processes. The Service Desk is the

first point of contact for most "users". However, the "customer", who hascommissioned and paid for the service, will initially contact IT Customer Relationship

Management. IT Customer Relationship Management provides a bridge between the IT

organization, which has traditionally taken a technical approach, and the customerswho want to fulfill their business objectives.

Service Level Management

The objective of Service Level Management is to make clear agreements withthe customer about the IT services required, and to implement these agreements.

Consequently, Service Level Management needs information about the customer

needs, facilities provided by the IT organization, and the financial resources available.

Service Level Management addresses the service provided to the customer

(Customer Focus).

- 36 -




By analysing the information needs of the customer (Information Pull) rather thanwhat is technically feasible (Technology Push), the IT organization can improve

customer satisfaction.

The chapter on Service Level Management in the Delivery book describes:

How, by clearly defining, a Service Level Agreement can optimize the ITservices at a cost that can be justified to the customer.

How the service can be monitored and discussed.

Underpinning Contracts support the service with sub-suppliers/sub-contractors.

Financial Management for I T Services

Financial Management addresses the prudent provision of IT services. For example,

Financial Management provides information about the costs incurred while providing IT

services. This enables a proper consideration of costs and benefits (price andperformance) when deciding on changes to the IT infrastructure or IT services. Theidentification, allocation, forecasting and monitoring of the costs, as discussed in the

chapter on Financial Management in the Service Delivery book, are all covered by the

term ‘costing’. These activities support cost awareness (what cost is incurred where?)and can also be used in drawing up budgets. With respect to the revenue stream of the

IT organization, this ITIL book describes various charging methods.

Capacity Management

Capacity Management is the process of optimising the deployment of IT resources, to

support the agreements made with the customer. Capacity Management addresses

resource management, performance management, demand management, modeling,capacity planning, load management and application sizing. Capacity Managementpromotes planning to ensure that the agreed Service Levels can also be fulfilled; now

and in the future.

Availability Management

Availability Management is the process of ensuring the appropriate deployment of

resources to support the availability of IT services agreed with the customer.Availability Management addresses issues such as optimising maintenance, and design

measures to minimise the number of incidents.

IT Service Continuity Management

This process addresses the preparation and planning of disaster recovery measures for

IT services. Other common names are Contingency Planning and Disaster Recovery

Planning. The starting emphasis for IT Service Continuity Management is therequirement to safeguard the continuity of the customer organization in the event of a

disaster (this means that the IT organization must be aware of the "BusinessContinuity Plan"). IT Service Continuity Management is the process of planning and

- 37 -




coordinating the technical, financial and management resources needed to ensurecontinuity of service after a "disaster", as agreed with the customer.

Security Management

The objective of Security Management is to protect the IT infrastructure against

unauthorized use (such as unauthorized access to data). This is based on securityrequirements laid down in Service Level Agreements, contractual requirements,

legislation, and policy. When updating the Service Delivery part of ITIL it was decided

that the recently published book on Security Management did not have to be replaced.The ITIL book on Service Delivery does not address security management directly but

refers to the Security Management book.

Service Support

The ITIL book on Service Support describes how a customer can get access to

the appropriate services to support their business.

This book covers the following subjects:

• Service Desk

• Incident Management

• Problem Management

• Configuration Management

• Change Management

• Release Management

- 38 -




Configuration Management

Configuration Management addresses the control of a changing IT infrastructure

(standardisation and status monitoring), identifying configuration items (inventory,mutual links, verification and registration), collecting and managing documentation

about the IT infrastructure and providing information about the IT infrastructure to all

other processes.

Change Management

Change Management addresses the controlled implementation of changes to the ITinfrastructure. The objective of the process is to determine the required changes, and

how they can be implemented with a minimum adverse impact on the IT services, byeffective consultation and coordination throughout the organization. Changes are made

in consultation with the status monitoring activities of Configuration Management, thecustomer organization, Problem Management and several other processes. Changes

are implemented by following a path of definition, planning, building and testing,

accepting, implementing and evaluating.

Release Management

The actual implementation of changes is often carried out through Release

Management activities. Both hardware and software (central processing, datacommunications and clients) changes are often planned on the basis of releases. The

main objective of Release Management is to control the distribution of hardware andsoftware, including integration, testing and storage.

Release Management ensures that only tested and correct versions of authorized

software and hardware are provided. Release Management is closely related toConfiguration Management and Change Management activities.

IT Infrastructure Management

Eventually, technical operational management processes will be addressed in anew ITIL book on IT Infrastructure Management. This book will cover:

• Network Service Management

• Operations Management

• Management of Local Processors

• Computer Installation and Acceptance

• Systems Management

IT Infrastructure Management also includes Environmental Management.

- 40 -




Applications Management

The ITIL book on Applications Management will address the relationship

between management and the software lifecycle. This includes issues such as SoftwareLifecycle Support and testing IT services. A major issue in Applications Management is

effectively responding to changes in the business. Clearly defining the requirements

and implementing a solution that meets the needs of the customer organization isparamount.

Software Lifecycle Support

Software Lifecycle Support aims to define the approach for supporting the

entire software lifecycle, in consultation with those responsible for software

development. The way in which software is designed, built, tested, introduced,operated, maintained, and eventually decommissioned, is extremely important

in IT services. In every stage of the software lifecycle, there have to beagreements between those developing and those operating the IT

infrastructure. The selection of Software Lifecycle models can have a significant

impact on the IT services.

Testing an IT Service for Operational Use

The objective of testing an IT Service for Operational Use is to ensure that theproper operation of new or modified IT services is tested before they enter

operations. A system test, installation test and acceptance test are undertakento determine if the developed application works, is correctly installed, interfaces

with the rest of the IT infrastructure, and offers the "users" the functionsagreed with the "customer".

Management and Organization

The ITIL series also includes some books on subjects at the strategic level, theManagers Set.

Developing policies and long-term planning of IT services are specifically

addressed in the books on Quality Management, IT Service Organization and Planningand Control for IT Services.

Quality Management for I T Services

Quality Management for IT Services addresses setting up and maintaining acoherent quality system, based on the IT Service Management processes

described in other ITIL books. This book describes the introduction of a qualitymanagement system (based on the ISO-9000 series of standards) in an IT

organization, and the evaluation of an existing quality management system.The relationship between the ISO standards and ITIL modules is also identified.

Quality Management activities include defining and implementing the quality

policy and managing the quality system, including audits.

- 42 -




IT Services Organization

IT Services Organization addresses the structure of the IT organization. This

ITIL book describes how the organization can be analysed and assessed,particularly in terms of tasks, authority and responsibility. A framework is

provided for dealing with organizational changes, based on the process

descriptions in the other ITIL books. Major activities in this process includedetermining and defining the organizational structure and role and function

descriptions.

Planning and Control for IT Services

Planning and Control for IT Services aims to provide a coherent system of planning, reporting and control for the IT organization, to ensure that the

organization fulfils the objectives and requirements based on the businessstrategy and the strategy of the IT organization. This includes coordinating the

planning and reporting of the various IT Service Management processes (for

example in the form of annual plans and quarterly reports).

Planning and Implementation

There is now much experience throughout the world with planning andimplementing programmes to optimize IT Service Management. A recent ITIL book is

devoted to this subject.

In essence, the concept of planning and implementing changes in IT ServiceManagement processes is shown in the process improvement model. In practice, the

situation illustrated by this model is often obscured by the way in which importantdecisions are taken in organizations, which may be affected by historical and political

issues. It is therefore necessary for management to commit to the improvementprogramme (Management Commitment), and for them to understand the

organizational culture. You should also be aware that there will generally already beprocesses that meet the needs of the organization, albeit only partly.

Lack of commitment will create resistance from the very people needed to align

these processes with the business needs. And alignment is at the very heart of benefitsgained in a process driven approach for IT Service Management.

- 43 -




Analysing the needs of the organization and implementing the required solutioncould require the creation of a temporary organization. This could be considered as a

one project, or as a series of projects in an improvement programme. One advantageis that it will provide the organization with clear decision points where it can decide to

terminate, continue, or modify the project. In this context, the ITIL books recommendthe adoption of PRINCE2 (Projects IN Controlled Environments) as a Project

Management methodology.

Each project is based on an analysis of the current situation, the desiredsituation, and the path in between. In most cases, the alternatives will be compared on

the basis of:

• Advantages to the organization

• Risks, obstacles and potential problems

• Transition costs and long-term costs

• Costs of continuing the current approach

Identifying the potential alternatives may well be a project in itself.

You should be aware that ITIL is no magic formula. Do not expect miracles. You

should be particularly wary of so-called ITIL implementation projects that have ahidden agenda, such as a reorganization or merger. ITIL describes the best practice for

improving IT Service Management; it is not an organizational handbook. ITIL primarilyprovides a frame of reference for process structures in the IT organization and, to a

much lesser extent, a guideline for the structure of that organization. If a project aimsto improve the IT organization along these lines, then it is wise to seek out experts in

this field (a good starting point is outside consultants who are certified IT Service

Managers (according to the certification requirements laid down by Exin or the ISEB).

A baseline measurement or health check can provide a good start for process

improvements. Such an assessment of the IT Service Management processes can helpidentify the strengths and weaknesses of the organization, and define clear objectives

for an improvement project.

After some time the measurement can be repeated to show the progress of theproject or programme.

- 44 -




Service DeskIntroduction

Here is a familiar situation.....

You have just started a complicated job, which requires all your concentration.

The phone rings....Someone is facing computer difficulty!!! The printer is not working.You solve the issue and just when you are back into the job …

Someone walks into your office asking when his or her expected upgrade will be done.

1 hour later you still haven’t started your job…..

Wouldn’t it be great if you could complete this job without interruption?

It is the role of the Service Desk to act as the single contact point between thecustomer and the IT Service Provider.

They will handle all incoming calls and only direct them through to the secondor third level support when necessary. For the customer the advantage is that they

don’t have to ring around, before finding the right person to solve their problem andfor IT personnel it means that they only have to deal with issues that are related to

their skills or area of responsibility.

Objective

The Service Desk offers "first line" support to users. Users need help if they arenot sure how to behave in a specific situation when using IT services or when theyneed assistance to solve a particular issue involving IT.

As well, the Service Desk is the central point of contact where incidents or

inaccuracies in IT systems can be reported. The Service Desk is the face of the ITdepartment to the clients. Furthermore, the Service Desk is an important source of

management information.

Objectives of the Service Desk:

• To provide a single point of contact for Customers

• To facilitate the restoration of normal operation service with minimal business impact

on the Customer within agreed service levels and business priorities

Process Description

The Service Desk is not regarded as a process within ITIL but as a function.

- 45 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=537&een=Service_Desk&uitklap=537&language=7&linkeen=537&menugroup=%27,%27inzien.asp?var=537%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=537&een=Service_Desk&uitklap=537&language=7&linkeen=537&menugroup=%27,%27inzien.asp?var=537%27)




As IT has become a greater part of business over the years the role of the ServiceDesk has become crucial. Businesses relies on there IT service to stay on top of the

market and be competitive. The service provided by the Service Desk tends to bebroader then just the IT part of business hence the change in name from Helpdesk

(which was more IT related) into Service Desk.

It plays a vital role in IT Service management as from a customer point of view theservice desk is the IT Service Provider and therefore plays a critical part in how the

customers perceives the IT organization as a whole.

Among the activities performed by the Service Desk are Incident recording and

Incident Control. This used to be part of the Helpdesk Process but is now included inthe process called Incident Management (covered in a later module).

Activities

The Service Desk has a number of primary responsibilities. These are:

• To provide a single point of contact for the customers;

• To facilitate the restoration of normal operational service (with minimal

business impact on the Customer) to the agreed service levels and according to

the business priorities.

Activities

1. Keep users informed by....

2. Providing information, in the form of:

• The status of their incident

• Planned changes in IT Service

• Likely disruptions in the IT Service

• Any changes or additions in the services that are

provided or the service levels.

The obvious benefits in proactively providing service information is that:

If the customers know before hand that a specific service(e.g. email) will be unavailable during the lunch hours you(a) reduce the amount of calls being received but also (b)reduce the impact of the disruption. The end result will befewer angry or annoyed customers.

3. Provide management information

- 46 -




By logging all calls the Service desk can provideinformation to Management about, the amount off calls

per category, the amount of calls as a result of a changeetc. But also in case of a disruption in the IT Service they

are likely to be the first to know. This makes the ServiceDesk an excellent First Point of contact for users,

customers and management alike.

The objective is to produce reports from which management can makedecisions and measure performance based on agreed service levels and

deliverables.

4. Conduct customer satisfaction analysis and surveys

5. Recording and controlling of incidents

Incident control

The Service Desk is responsible for recording all incidents and then controlling them.The Service desk can use different ways in recording the incidents:

• Phone

• E-mail• Internet

• Fax

• Personal visit

By making use of different ways of recording incidents and even automating thesolution then the workload of the service desk will be reduced and by association sowill the costs.

Think about how much time it costs to reset a password for a user and how oftenthat is required. If by sending an email a set of actions would be started including:creating the incident, resetting the password, informing the customer and closing theincident a great deal of time could be saved.

- 47 -




Roles

The new Service Desk tends to be more then the just the place to lodge calls related to

IT. It has a role to provide and improve the service to the business in general. Thechanging role is that the Service Desk is a more customer focused, whereas the

traditional Help Desk tended to be more technical in nature.

As there are different types of Service Desk models the skills required by the ServiceDesk staff also must be carefully analysed.

Interpersonal skills are one of the more important ones. Technical skills become moreimportant when the Service Desk becomes more skilled and aims to solve most of the

incidents without rerouting them to higher levels of support.

Relationships

Being the single point of contact for IT Service, the Service Desk has a link with all

processes within ITIL. With some processes the link is a clearer than others.

The Service Desk is, in fact, an operational aspect of the important processof Incident Management, e.g. incident control. The Service Desk registers and "controls"

Incidents.

Incidents can be related to Configuration Items. If this link is supported by software,

a powerful aid in mapping/identifying weak links in the IT infrastructure evolves.

This allows the Service Desk staff the to quickly solve incidents by searching on a

Configuration Item, category and/or error code and applying a previously used solution.

- 48 -




Note: A Configuration Item (or C.I.) is discussed in the Configuration Management process

section. A C.I. is an item that we want to store information about.

In some cases the Service desk does some minor changes and so has a link with

Change Management and Release Management.

The link between the Service Desk and Service Level Management can beillustrated as a result of the Service Desk monitoring Incident levels and reporting

whether the IT service is restored within the limits defined in Service Level Agreements(SLA's). Service Desk will report to Service Level Management if IT Service is not

restored within time frames and escalation procedures are properly defined andadhered to.

Benefits

The benefits from a properly implemented Service Desk flow across Users, Customers,IT Staff and the business as a whole.

Note: The difference between a Customer and a User should be explained. A Customer is the person who may

often be the representative of the business for the service provided and/or the person who funds the service.

The user is the ultimate end user of the service provided.

- 49 -




Benefits for the Customer

• Easily defined metrics for measuring performance

Benefits for Users

• Single point for all queries

• Better informed

• Quicker turn around of request, queries and incidents

Benefits for IT staff

• Being able to focus more on the job

• Greater efficiency

• Better use of the skills the staff has resulting in motivated personnel

• Improved team work

Benefits for the business

• Source of useful management information

• Internal cost savings and productivity efficiencies

• Meet customers business support requirements with responsiveness at all timeswhen and wherever it is needed

• Better use of available resources

Summary

An effective Service Desk will deliver overall cost reduction and increases instaff morale, service reliability and identification of business opportunities. All this

leads to increases in Customer satisfaction ratings, with the associated improvement inperception this brings.

- 50 -




Common Problems

There is no doubt in denying that along with any move towards improvement there

will be problems and barriers to success. Recognising this in advance goes a long wayto solving the problem when (not "if") it comes up.

• Users do not call the Service Desk, but try to go around it to the person theyknow, the one who helped them so well the last time.

The Service Desk needs to be easily accessible, easy toremember phone number, out of office process

established, after hours process established, low waiting

times and different ways of communicating/interfacing.Processes for dealing with different levels of staff within

the organization (eg. creating a group of "Critical Users")will also ensure that Service Desk staff realistically deal

with those in highly critical roles as a top priority.

All Customers must be redirected to the Service Desk if

they try to contact someone directly. This can be done

politely and does not have to be used as a threat (eg. "if you don't contact the Service Desk, we won't help you"

versus "if you can contact the Service Desk it will meanthat we properly track and fix your problem").

Users who wish to circumvent the proper procedure will be annoyed and

cause disruption. However, this short term problem should be ridden out,

rather than "giving in". In time, all users will become accustomed to

change and eventually start to accept and see the benefits (refer to SD

Benefits).

• Not aware what the needs of the business and/or users are.

If the Service provided by the Service Desk (IT ServiceProvider) is not the one needed by the business or the

user then it matters little that the service is perfect.

If a business is only operatingbetween 9 am and 4 pm, having a ServiceDesk that’s is open 24 hours a day, is notvery useful and might result in understaffing of the Service Desk during the

business hours.

• Not all parties involved are informed about the Service provided and the ServiceLevels agreed upon, resulting in unrealistic expectations.

This is a simple case of communication and making sure

that that all procedures, Service levels etc are well

- 51 -




documented and available to all parties involved. Alsoperiodically revisiting and re-educating involved staff,

BEFORE issues arise.

This is not to say that staff will use this information against users who

require service, it simply means that users approach the Service Desk with

realistic expectations. Naturally, everyone's problem is critical when ithappens - when a user is irate or stressed it is not appropriate to point out

that the agreed service levels allow for a 48 hour response. This highlights

the people skills that Service Desk staff need to have.

A well-marketed Service Desk is only half the job.I n v o l v e key customers in the process of implementing the Service Desk and reap therewards from having their support in times of crisis.

Metrics

Metrics are essential in monitoring any IT Service provided. The Service Desk asa service for users is no different in this regard.

Day to day reports can provide information on Calls and Incidents. For instance;

• How many and what kinds of incidents (classifications) the Service Desk solvesat first point of call.

• How long calls last, how many there are and how long the waiting time is beforea call is answered. This information can be extracted from appropriate tools orfrom PABX records.

If standards are set before the Service Desk starts operating one can monitor

the progress of the Service Desk. The crucial factor is in defining what it is that shouldbe measured. It is realistic to start with a very simple set of metrics and possibly this

is a better approach as it means that there is no time lost in creating a long series of reports that add no value to a customer.

The easiest way to begin to define what metrics are required is to look to the Service Level

Agreements (SLA's) that should define the response times, etc. for the Service Desk from the Customer

perspective.

However, even if all Service Levels are met the most important measurement

for any Service organization is the perception of the Customers of the service provided.Therefore Customer satisfaction should be measured regularly.

- 52 -




- 54 -




Centralised Service Desk

A centralised Service Desk is a physical point in one location. All users from the

different sites contact this one Service Desk.

This model leads to a reduction in operational costs, easier management of the IT

Service and better use of Resources.

Virtual Service Desk

Due to advanced network and telecom technologies it is now possible to have a

Service Desk that has no physical location as far as the user is concerned. It might bestaffed in different locations at different times during a day resulting in a 24 hour

Service Desk.

The issue to consider is the need for a physical engineer at the various locationsto solve local incidents. Also time differences have to be taken in consideration when

setting up Service Level Agreements.

- 55 -




Virtual Service Desk

Hybrid models combine two or more of these particular structures into a

customised solution for a particular organization. This is a genuine structure as theITIL Framework provides guidelines only for structure and is not a prescriptive solution

book.

Interesting websites:

• http://openview.hp.com/products/servicedesk/ • http://www.interpromusa.com/hdicerti.htm

• http://www.interpromusa.com/The Integrated Service Desk.pdf • http://www.itilworld.com/n-america/service-support_helpdesk.htm

• http://www.itil-service-support-management.com/Pages/Service support/ServiceDesk/Service_Desk_scope.htm

• http://www.itil.co.uk/online_ordering/serv_supp_graphs/serv_desk.htm

- 56 -

http://openview.hp.com/products/servicedesk/

http://www.interpromusa.com/hdicerti.htm

http://www.interpromusa.com/The%20Integrated%20Service%20Desk.pdf

http://www.itilworld.com/n-america/service-support_helpdesk.htm

http://www.itil-service-support-management.com/Pages/Service%20support/Service%20Desk/Service_Desk_scope.htm


http://www.itil.co.uk/online_ordering/serv_supp_graphs/serv_desk.htm

http://www.itil.co.uk/online_ordering/serv_supp_graphs/serv_desk.htm



http://www.itilworld.com/n-america/service-support_helpdesk.htm

http://www.interpromusa.com/The%20Integrated%20Service%20Desk.pdf

http://www.interpromusa.com/hdicerti.htm

http://openview.hp.com/products/servicedesk/




Essential Terms

Escalation:When the time limit for resolving an incident has passed, the incident escalates into aproblem (depending on the priority and impact of the incident) and a different level of

support (Problem Management) comes into force and this:

• Edits the problem if necessary

• Determines the impact on the service delivery and with that, the priority. TheService Desk continually informs clients about the progress of their calls.

Routing:An incident is deposited at the second line support because no specialist knowledge forthe solution is available at the Service Desk

Incident:An incident is every operational event that is not part of the standard operation of an

IT service. An incident influences the service delivery, although it can be small and in

some cases even transparent (not noticeable) for the user.

Problem:A problem is the as yet unknown cause of the occurrence of one or more incidents.

Known error:

This is the situation where a successful diagnosis of a problem has shown what thecause is and which CI is at fault. A possible solution may also be found as to how the

problem can be avoided.

Expert or Super user:

Some organizations may use “expert” users to solve some first line support queries,

depending on the structure of the organization. This can solve some short term peopleresource issues.

CallEach time the user contacts the service desk.

- 57 -




Process Description

As with every process there is an Input and an Output.

The main input to this process are incidents. As shown in below Incidents can

come from many sources like users, management Information or infrastructuremonitoring tools.

The Input for Incident Management mostly comes from users, but can have

other sources as well like management Information or Detection Systems.

The outputs of the process are RFC’s, resolved and closed Incidents,management information and communication to the customer.

This concept is illustrated in the following diagram. The centre diamond showsthe activities of Incident Management.

- 59 -




Activities

The activities included in Incident Management are:

• Incident detection and recording

• Classification and initial support

• Investigation and diagnosis

• Resolution and recovery

• Incident closure Incident ownership, monitoring, tracking and communication

Incident detection and recording

Throughout an Incident lifecycle specialist IT groups will handle the incident at

different stages. To do this efficiently and effectively a formal approach is required,which will facilitate the timely restoration of service following an incident.

As shown incidents come from many sources. The Service Desk (more

commonly known as a Help Desk) is the primary point for recording incidents, althoughother IT staff can play this role as well. The Service Desk is the single point of

contact between service providers and users, or their representatives, on a day-to-day

basis and typically the owner of the Incident Management process.

Incident tracking is highly recommended. Information about incidents should beheld in the same Service Management tool as problem, known error and change

records. Records should be cross-linked to eliminate the need for re-keying data. This

improves information interfaces and makes data interrogation and reporting far easier.

Incident priorities and escalation procedures need to be agreed as part of the

Service Level Management process and documented in SLAs.

Classification and initial support

Incidents should be classified according to three criteria (Priority, Impact & Urgency).

Priority One of the important aspects of managing an Incident is to define its priority. How

important is it and what is the impact on the business? The responsibility for thisdefinition lies with the Service Level Management process. The priority with which

- 60 -




Incidents need to be resolved, and therefore the amount of effort put into theresolution of and recovery from Incidents, will depend upon:

o The impact on the business

o The urgency to the business

o The size, scope and complexity of the Incident

o The resources availability for coping in the meantime and for correctingthe fault.

Impact 'Impact' is a measure of the business criticality of an Incident or Problem. Often this

equates to the extent to which an Incident can lead to degradation of agreed servicelevels. Impact is often measured by the number of people or systems affected. Criteria

for assigning impact should be set up in consultation with the business managers andformalised in SLAs.

When determining impact, information in the Configuration Management Database

(CMDB) should be assessed to detect how many users will suffer as a result of the

technical failure of, for example, a hardware component. The Service Desk should haveaccess to tools that enable it rapidly to:

o Assess the impact on users of significant equipment failures

o Identify users affected by equipment failure

o Establish contact to make them aware of the issue

o Give a prognosis

o Alert second-line (specialist) support groups, if appropriate

Urgency 'Urgency' is about the necessary speed in solving an Incident of a certain impact. A

high-impact Incident does not, by default, have to be solved immediately. For examplea User having operational difficulties with his workstation (impact 'high') can have the

fault registered with urgency 'low' if he is leaving the office for a fortnight's holidaydirectly after reporting the Incident.

Urgency is seen as to what degree the service is affected (stopped, partially affected,

functionally changed). If a user calls with an Incident and they can’t work (servicestopped) then it is of greater urgency than a user calling to request a functionality

change.

Investigation and diagnosis

Once logged the activity of investigation and diagnosis will take place. If the

Service Desk can’t solve an Incident it will be assigned to other support levels. Theywill then investigate the Incident using the available skills sets and tools such as a

knowledge base of Known errors etc, and diagnose the problem. It is important that allparties that work on the Incident keep record of their actions by updating the Incident

record.

- 61 -




Resolution and recovery

Once a "work-around" or a solution to the incident is found it will be

implemented. If a change is needed an RFC will be submitted to Change Management.

Incident closure

For the Incident Management process to be effective it is necessary that the Incidentsclosure be done properly. This step includes:

o Updating Incident details

o Communication with the user about solution

To ensure the solution provided meets the user needs they are the only personthat can give the authority to close an Incident. The Incident record in the Service

Desk tool should be ‘closed’ so that accurate reporting can be carried out.

An Incident will be closed as soon as the agreed service is restored.

In some cases the Incident record is closed but a Problem record is still open

(Refer to Problem Management for more information about a Problem record).

Incident ownership, monitoring, tracking and communication

Whilst an Incident may be passed across different IT groups duringinvestigation and diagnosis the Service Desk remain the owner of the Incident (in

terms of tracking through to closure). They will monitor the progress of the Incident in

light of service levels and maintain/manage communication with the user. If theIncident is not progressing appropriately then the Service Desk may trigger either a

functional or hierarchical escalation. These different types of escalation are coveredin the Best Practices section.

Roles

The role of Incident Manager in most organizations is assigned to the Service Desk

Manager.

The Incident Manager role includes responsibility for:

• Monitoring the effectiveness and efficiency of the process

• Controlling the work of the support groups

• Making recommendations for improvement

• Developing and maintaining the Incident Management system

• Reporting to management and other process areas

- 62 -




Support roles:

First line support will be done by the Service Desk and includes the recording,

classifying, matching, routing, resolving and closing incidents.

Second and third level support is responsible for in investigation, diagnosis, and

recovery from incidents.

Relationships

Incident Management has a close relationship with other ITIL processes. Someof these inter-process relationships are described here.

Configuration management:

Every Incident is connected to a Configuration Item (C.I.) stored in the CMDB.

An incident will typically involve more than one C.I.

The CMDB provides information about CI’s and the parent/child relationshipsbetween them. This helps to determine the cause, solution and routing of an incident

by tracing a fault back through the C.I. relationships. For example, if a user cannotaccess the Internet, by looking back through the parent/child relationships of that

users PC could find that a Hub that the user connects to (parent of the child PC) is apotential C.I. that should be investigated.

Problem Management

Incidents with unknown causes are routed to Problem Management where they

are processed.Known Errors, Work-arounds, Quick Fixes is given to Incident Management by

Problem Management.

Change Management

This process can be the cause of Incidents if a Change is not implementedcorrectly. Therefore it is very important that Incident Management knows all planned

changes so they can relate Incidents to a change and notify the Change Managementprocess so that roll-back plans can be implemented if necessary.

On the other hand some Incidents will be solved by a Change, as will be the case whenfaulty equipment is replaced.

- 63 -




Service Delivery Processes

Incident Management provides and gets information from all the ServiceDelivery processes. Service Level Management, for example, is responsible for

establishing service levels that relate to work done within the Incident Managementprocess. The Service Desk will then report against these service levels.

Benefits

A well implemented Incident Management process will have easily visible

benefits. Unlike some other ITIL processes where benefits may be hard for end usersto identify, the benefits of good incident management will be felt by them directly.

For customers

• Quick restoration of Service following an Incident• Incidents are not lost or forgotten

• Up to date status of their Incident provided

For IT Organization

• Remove the problem of duplication of effort (once an Incident is solved the

resolution will be easily found and can be applied to future incidents if the re-

- 64 -




occur or the resolution can be a starting point for a different but relatedincident).

• Clear view of the status and priorities of the Incidents

• Possibility to measure performance against SLA’s.

• Higher user and customer satisfaction

For the business

• Prioritisation - the high impact, high urgency, incidents are the ones that jump

to the front of the queue. Resulting in the least possible impact on the businessactivities.

• Quicker resolution of Incidents leading (productivity gains).

• Management information is provided.

Defining benefits is relatively easy. Realising benefits is difficult as during times of incident a lot of end users will not want to be convinced that their incident is not a high

impact/high priority task and that there are other incidents demanding attention ahead

of them.

This is where the communication skill of IT Staff must be at it's highest (and most

tactful). Carefully selecting the words used to convey this message can be learnt. Forinstance acknowledging the frustration they are facing and providing a very brief

overview of the things ahead of them in the queue. This way the person can

(hopefully) understand that there are more pressing issues ahead of theirs. Notdismissing their call as "unimportant" or "I'm busy with other people" or "You'll have to

wait".

Common ProblemsWe know there are many benefits of a good incident management process.

Likewise, there can be some real "show stoppers". The following major obstacles if not

dealt with will mean the process will be inefficient and ultimately unsuccessful.

Critical Success factors for successful Incident Management:

• A CMDB needs to be set up before Incident Management is implemented. This

makes the determination of impact and urgency a lot faster. The CMDB willideally be an electronic system, but it can be a manual system.

Note: The CMDB is the Configuration Management Data Base. The CMDBis covered in the Configuration Management process chapter. The CMDBholds information about C.I.'s (Configuration Items).

• A knowledge database. This database will hold Known errors, work arounds and

resolutions. This will help Incidents to be resolved much faster and with lesseffort.

- 65 -




• An Incident Management tool to record and monitor Incidents easily.(Preferably this tool is part of a complete Service Management tool that

integrates the tools from all processes).

The challenge in the implementation of these tools and databases is not to let the

work of setting up the system stand in the way of making progress.

Any ITIL process can be started in a very simple form. The biggest challenge

facing IT professionals is that it takes "discipline" to use the tools and procedures.

The sooner the discipline of logging information, searching for solutions rather than re-working solutions can begin, the better.

If people start to use the tools and start to see benefits in doing so, then so theproper "habits" are formed. It is then a relatively easy task to modify behaviours to

use a different tool or introduce new features/functionality as tool development or toolselection progresses.

Metrics

Many metrics can be obtained from this process, some of the more notable and useful

are:

• Number of Incidents per time period

• Number of Incidents per category• Number of Incidents per priority level

• Incident resolution performance against service levels• Number of closed Incidents per time period

Best practice

Incident Management tools:

There are many Service Management tools on the market that now align and provide functionality to support

ITIL processes. These tools have many features, which assist in automating the process such as:

• Quick Call Logging (one click to log a call)

• Auto population of data • Automated alerts from infrastructure devices and applications that

automatically generate an Incident record

• Advanced knowledge bases

• Customisable reporting

- 66 -




Different types of escalation

In a functional escalation environment, the physical escalation of an incident usually

takes place because of either a lack of expertise at a specific level or due to servicelevels being breached.

Hierarchical escalation occurs usually more proactively (e.g. when the service deskidentifies early that there is the likelihood of a breach and escalates manually ratherthan waiting for the time lapse).

Incident life Cycle

The following diagram shows the activities throughout the Incident Management

process and the status that each activity can be set at. Throughout the activities thecontinual issue surrounding ownership, monitoring and tracking must also be

considered.

Interesting Websites

• http://www.helpdeskinst.com/publications/practices.asp

• http://www.itil-service-support-management.com/Pages/Service

support/Incident management/Incident_mgmt.htm

• http://www1.worldcom.com/au/resources/whitepapers/pdf/WorldCom_White_P

aper_On_eCRM.pdf

• http://www.itil.co.uk/online_ordering/serv_supp_graphs/incident_mngt.htm

- 67 -

http://www.helpdeskinst.com/publications/practices.asp

http://www.itil-service-support-management.com/Pages/Service%20support/Incident%20management/Incident_mgmt.htm


http://www1.worldcom.com/au/resources/whitepapers/pdf/WorldCom_White_Paper_On_eCRM.pdf


http://www.itil.co.uk/online_ordering/serv_supp_graphs/incident_mngt.htm

http://www.itil.co.uk/online_ordering/serv_supp_graphs/incident_mngt.htm





http://www.helpdeskinst.com/publications/practices.asp




• http://tools2manage-it.com/serv_mgt.php

Essential Terms

Incident

"Any event that deviates from the (expected) standard operation of asystem." An incident is often simply a user requesting help for something that is not working.

For example “I can’t see my network drive”, “I can’t access the Internet”, “I can’t sendemail”. It is any situation where something does not work and the specific details are

not known.

Work aroundIt is possible for Problem Management to identify “work-around” in the investigation of

problems. These should be made known to Incident Management so that they can bepassed to the user until the permanent fix is implemented.

Problem Management

Introduction

Problems have a tendancy to always happen !!. No matter how well things arerunning. Even with the most reliable IT, the service delivery will be troubled by

disruptions that cannot always be avoided.We have learnt that an incident is a deviation from standard operation. This

means that users can face many incidents and a lot of the time they will face the sameincident many times.

A user calls with an "incident" - the Service Desk captures the call and gives

great Incident Management support : "re-boot your PC and see if that fixes it". It does.The user is happy. The next day the same user calls with the same incident, with the

same great incident support. "Re-boot your PC". On the third day the user does notcall again, they just re-boot their PC and start to live with the issue. Then they start to

tell other users - just re-boot your PC that'll fix it. All of a sudden we have a plague of PC re-booting users !!!

So how do we avoid the plague? By introducing Problem Management. The firstincident that was fixed by re-booting the PC should have been passed to Problem

Management.

An example where Problem Management can make a difference: In an organization a user calls the Service Desk with the complaint that his

document is not printing. The Service Desk investigates the incident and sees that theprint queue has the status ‘On Hold’. The Service Desk releases the queue, thedocument is printed and the Incident closed. A few minutes later another users calls

- 68 -

http://tools2manage-it.com/serv_mgt.php

http://tools2manage-it.com/serv_mgt.php




Process Description

The Problem Management process is focused on finding weaknesses in the IT

infrastructure and through the use of Change Management removing them so that futuredisruptions do not occur.

The process focuses on finding patterns between incidents, problems and known

errors. These three areas are key things to understand in this "root cause analysis". The

basic principle is starting with many possibilities and narrowing down to a final root cause.

Note: "Root Cause analysis" is often used interchangeably with Problem

Management. The ITIL Framework doesn't prescribe what a process area should becalled and Root Cause Analysis is fine. However, Root Cause Analysis is typically

a reactionary exercise. ITIL's Problem Management caters for reactive work, but

more importantly recognizes the value of proactive problem management. We useRoot cause analysis interchangeably with Problem Management.

Incidents:

An incident is defined as a deviation from the standard expected operation of a service. It

is a general description of something that has gone wrong. It is not known what the exact

cause is at this stage. For example users will call a Help Desk and say, “I can’t print”, “Ican’t access the Internet”, “I can’t see my network drive”. They expected to be able to do

these things yet could not, so these are "incidents".

Problem:

A problem is the “unknown underlying cause of one or more incidents”. This is the

second stage of "root cause analysis"/problem management. From the general incidents,more investigation will uncover an underlying cause of these incidents. A “network

problem” is a good example of a problem definition in this case. Users don't call saying I

have a "network problem", they call and say "I can't save to my H: drive" or "I can't print orsurf the web". IT staff then piece all these incidents together and identify that we are facing

a "network problem".

Root cause analysis has taken us closer to finding the root cause but not completely. A

problem is then a more specific definition.

Known Error:

A Known Error is the final step in the root cause analysis process. A Known Error can be

defined as, “when the root cause of the problem is known”. In our network problem

example it is where the faulty equipment or system has been identified.

- 70 -




This is the end of the root cause analysis process. Following the above example the Known

error would be “Router x is faulty”.

From the above we see the initial general issues being faced through to the final definition

of the root cause. The following diagram illustrates this flow.

The process of Problem Management requires the following inputs:

• Incident records and details about Incidents

• Known Errors

• Information about C.I.’s from the CMDB

• Information from other processes (eg. Service Level Management providesinformation about required timeframes, Change Management provides

information about recent changes that may be part of identifying the known

error).

The outputs of the process are:

• RFC’s (Request for Change) to start the change process to solve the KnownErrors.

• Management Information

• Work arounds

• Known Errors

- 71 -




• Update Problem records and solved problems records if the known error issolved.

The following picture summarises this. The center diamond highlights the Problem

Management activities which we will look at in the next module.

Activities

The ITIL Problem Management has four primary activities as follows:

• Problem Control

• Error Control

• Proactive Problem management

• Completion of Major Problem Reviews

Problem Control

The Main activities within Problem Control are:

• Identification and recording of Problems

o Some problems can be identified by processes outside

Problem Management (eg. Capacity Management).

- 72 -




o It is also wise to note that the time, effort and cost thatgoes into fixing problems must be weighed up against the

benefits of doing so. If costs outweigh benefits a simpleProblem record can be created that links all affected C.I.'s,

RFC's and Incidents.

• Classification of Problems

o This activity centres on understanding what the impact onagreed service levels is of the problem. Classification of

problems is similar to Incident classification (impact,urgency, priority).

• Investigation and diagnosis of Problems

o This is the step where we get to understand what it is that

is causing the problem. This step is vastly different fromIncident Management investigation where the focus is"rapid restoration" of service.

- 73 -




Error Control

Error Control is the process in which the Known Errors are researched and

corrected. The request for change comes from this sub-activity and is submitted to Change

Management and then following approval the change is actioned.

Proactive Problem Management

The best problems are the ones that never happen. !

Proactive Problem Management focuses the analysis of data gathered from otherprocesses and the goal is to define “Problems”. These problems are then passed off

to Problem and Error Control procedures, as if they had happened.

The activity includes:

• Trend analysis

• Using data to highlight potentially weak components.

• Targeting preventative action

• Trend analysis can lead to identifying general problem areas.

- 74 -




The aim of proactive Problem Management is to redirect efforts away from always

being reactive, to proactively preventing incidents occurring in the first place.

Completion of Major P roblem reviews

At the end of a major problem cycle, there should be a review to learn:

1. What things were done right?

2. What things should we have done differently?3. What lessons do we take away from solving this problem?

Roles

Problem Manager role

The role of Problem Manager is responsible for:

• Developing and maintaining Problem Control and Error Control

• Assessing the efficiency and effectiveness of Problem Control and Error Control

• Providing management information• Managing Problem Management personnel

• Obtaining the resources for the required activities• Developing and improving Problem Control and Error Control systems

• Analysing and evaluating the effectiveness of Proactive Problem Management

Problem Support role

The Problem Support team is responsible for:

• Identification of Problems

• Investigation of Problems leading to the Known Errors

• Monitoring the Process of eliminating Known Errors

• Raise RFC’s when necessary

• Identify trends

• Communicate Work arounds and quick fixes to Incident Management

- 75 -




Relationships

The Problem Management process has a close connection with the following ITIL

processes"

Incident Management:

A very close and obvious link as we have learnt. Problem management aims to solvethe root cause for the Incidents that are recorded by Incident Management. It is

important that Incident Control provides accurate information so that Problem Controlcan solve the Known Errors easier.

Problem management will supply Incident Management with workarounds and quick

fixes where possible.

Change Management:

If Problem Management finds the solution to a Known Error they have to submit a RFCfor the Change. Change Management is responsible for the implementation of the

Change. When it is implemented they, together with Problem Management, review theProblem to verify that it is solved by the Change. This is called a Post Implementation

Review after which Problem Management can close the problem record.

Configuration Management:

The information that is provided by Configuration Management is important indiagnosing problems. It includes information about C.I.’s and relationships with other

C.I.’s.

Other processes:

Service Level management, Configuration Management and Availability management

all provide Problem Management with information, which help to define and determinethe impact of problems. In return Problem Management provide these and the other

process with relevant information, for example, to SLM if a problem causes a IT

Service to operate outside the Agreed Service levels or to Capacity Management if acertain hard disk is the cause of a Problem.

- 76 -




Benefits

Problem Management improves the IT service quality by resolving the root cause of

incident(s). This leads to lower amounts of Incidents - benefiting users, customers, theorganization and the IT department:

Advantages are:

• Better quality of IT Service Management

• Reliable IT Service results in a better reputation of the IT service

• Ability to learn from the past

• IT staff will be more productive• Higher resolution rate for Incidents at the Service Desk first time around

• Less Incidents

- 77 -




Common Problems

Common problems for Problem Management include:

1. Incident Management and Problem Management don’t have well definedinterfaces with each other.

2. Known Errors are not communicated to Service Desk/Incident Management 3. No Commitment from Management 4. Unrealistic expectations of the Problem Management process.

The following slide raise these and other points of attention that have to be considered.

- 78 -




Metrics

Successful Problem Management can be measured by:

• Reduction in Incidents because the underlying causes are removed

• The time that is needed to resolve Problems

• The other costs that are incurred associated with the resolution

Within Problem management there is lot that can be measured. It depends on the

scope of Problem management as to what is relevant.

Some examples are:

• Time spent per organizational unit fixing problems

• Number of RFC's raised

• Ratio of proactive to reactive problem management

- 79 -




Best practices

Considerations for Problem Management, a high-pressure area for IT.

The variety, complexity, volume and difficulty of problems facing Support teamstoday compared to the "early days" (those of a decade ago) seem child's play. Why?

Increases in user demand have led to vast numbers of PCs; distributed Client/Servernetworks; multi-site, multi-platform systems; cheap but complex software packages;

all in addition to the traditional mainframe systems, and all needing the same highlevels of technical support, and all to be delivered with a sensitive 'customer care'

attitude.

This increasing workload is threatening the whole stability of IT. If we don't finda lateral solution for managing it, demand will simply continue to grow at its present

rate. The result? Support functions will soon dwarf the rest of IT in terms of number of

personnel, running costs, and quality of expertise. And ignoring the problem, in thevain hope that it will go away, is even worse.

Demand must be managed down, resources re-allocated, recurring problemseliminated, and difficulties anticipated and addressed before they become problems.

Aggressive, effective and financially viable Problem Management is an integral step inachieving this. Otherwise IT will simply grind to a halt, grid locked and unable to

function.

- 80 -




Note: the following web links provide some additional research material. TheKepner-Tregoe link is an interesting one. KT Analysis is a long serving tool that can

be very useful in carrying out the Problem Management process activities.


• http://www.itilworld.com/n-america/service-support_probmanage.htm

• http://www.kepner-tregoe.com

• http://www.itil-service-support-management.com/Pages/Service

support/Problem management/Problem_mgmt.htm

• http://www.itil.co.uk/online_ordering/serv_supp_graphs/problem_mngt.htm

Essential Terms

Work Around:

A "quick-fix" solution to an incident , which will produce an acceptable outcome for a

limited period.

Proactive Problem Management:

Activities aimed at removal of errors while the errors are in a state of inactivity.

Key success factors in Problem Management:

• Automated registration of incidents with correct classification.

• Setting attainable objectives of the Process. Depending on the size of theoperation, not even treating this as a full time role.

• Good inter-process co-operation (especially Incident and Change).

- 81 -

http://www.itilworld.com/n-america/service-support_probmanage.htm

http://www.kepner-tregoe.com/

http://www.itil-service-support-management.com/Pages/Service%20support/Problem%20management/Problem_mgmt.htm


http://www.itil.co.uk/online_ordering/serv_supp_graphs/problem_mngt.htm

http://www.itil.co.uk/online_ordering/serv_supp_graphs/problem_mngt.htm



http://www.kepner-tregoe.com/

http://www.itilworld.com/n-america/service-support_probmanage.htm




Change Management

Introduction

As organizations become more dependent on IT services and technology

changes rapidly succeed one another, the need for proper management and control of

change grows with it. Many problems in the quality of IT Service Support emerge fromchanges in existing IT systems. The ITIL Change Management process is designed to

act as a planning and control process. Proper planning and control ensures theimplementation of change can take place without interrupting the operational IT

service delivery.

It is Monday July 1st. End of financial year. For many organizations it is thetime of the year to close out and get final figures for the previous 12 months. Lots of reports being run, lots of heavier than normal requests on systems, lots of printing,etc.

Imagine then a Service Desk where the phones start ringing at the start of theday. “My report is not showing any figures.” “I can’t find any details of last year.” “Allfigures for last year are lost.”

Mild panic quickly escalates to all out concern as no-one really knows what hashappened. They all individually try and solve the incident of each user by investigatingthe software etc. Nothing seems to be wrong, with the system functionality, it's justthat the reports are all blank !

By now the IT Director is looking for some answers from his staff. He has toreport to the business manager on what has happened and why should he keep his job!

Then one of the Service Desk staff strolls in. He's had a late start as he workedback last night. He notices the panic and asks what is wrong. When he hears the storyhe turns red and tells them about the change they made the night before. You canhear a pin drop !

He thinks he may have caused the problem. They look into it and it seems it isthe problem so the staffer is asked to roll-back the change. Only trouble is no-oneseems to have kept a copy of the configuration prior to the change. So, the only wayto solve this issue is to correct the problem in the change. At the end of the day theproblem is fixed and the figures for last year are back. Things start to go back tonormal at the Service Desk …

But the IT Director stills feels the wrath of the business people, along with theknown business cost of the lost hours of productivity and still considers finding anotherrole !

- 82 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=544&een=Change_Management&uitklap=544&language=7&linkeen=544&menugroup=%27,%27inzien.asp?var=544%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=544&een=Change_Management&uitklap=544&language=7&linkeen=544&menugroup=%27,%27inzien.asp?var=544%27)




This is a situation that you want to avoid and with a good Change Managementprocess it is possible!

In our example, with ITIL Change Management in place:

• The Service Desk would have known about a change being done the night

before so they could have made the connection between problem and change alot earlier.

• The change wouldn’t be scheduled prior to such an important day in this

organization because of the risks involved.

• The Change would have been tested properly so the whole issue might have

been avoided.

• A proper roll-back would be in place resulting in a quicker solution of the

problem.

ObjectiveFor an effective and efficient IT service delivery it is necessary to have the

capability to implement many changes correctly. Changes in reality often lead to

(implementation) problems.

The created problems are subsequently resolved by the implementation of achange, which in turn leads to more problems. Breaking this negative spiral is an

important task for Change Management.

ITIL's goal statement for Change Management is...

"Assuring that standardised methods and procedures are in use for theefficient and timely implementation of all changes, in order to minimise theimpact of change related problems on the quality of the IT service delivery".

The goal also build an internal understanding of the "how and why" for the

process (how = standardised methods and procedures, why = to minimise impact).

Remember....

" No t eve ry Change i s an i mpr ovement b u t eve ry i mpr ovement r equ i res a change"

Process Description

The common trigger for Change Management is a Request for Change (RFC).RFC's come from within the IT organization as well as from the Customers.

- 83 -




Determining the scope is a dynamic activity, as the scope can change andtherefore the need for information needed from the CMDB can change as well.

Reviewing the scope on a regular basis is important.

It is not necessary that not all changes are controlled by the Change

Management process. For example minor changes, such as resetting a password etc

can be done by the Service Desk (following set procedures) but doesn’t need to becontrolled by Change Management. To do so, would lead to increased workload,

frustration and "by-passing" the process.

Activities

The Change Management process includes the following activities:

• Recording

• Accepting

• Classifying

• Planning

• Co-ordination of activities

• Implementing

• Evaluating

Recording

Although this activity is not carried out by Change Management itself, it is the

responsibility of Change Management to make sure all Changes are recorded correctly.

Accepting (Rejecting)At this stage RFC’s will be reviewed and accepted or rejected. Any rejection shouldalways be communicated and explained. A reason for the rejection of an RFC might be

that it is incomplete or illogical. Accepted RFC's then be classified.

Classifying

In this stage the RFC will be categorised and a prioritised. The category

depends on the impact the change has and the resources needed to do the change.

The priority is derived form the urgency and the impact of the change, along

with knowledge that the Change Management process may have from other processareas, that the change requestor is not aware of.

Planning

The change will be planned and put on the Forward Schedule of Change (FSC), if appropriate. The Change Advisory Board (CAB) meets to review the FSC. The FSC will

consist of:

- 85 -




- Planning in time, people, and budget- Indication of consequences for other changes

- Advice on whether the change should be a go or no-go

Coordination

If approved the change must be built, tested and implemented. Change

Management doesn't do this work, but it co-ordinates the activities to ensure progress

is made. Change Management will also verify that a back out plan has also beendeveloped and submitted for approval.

Evaluating

Each change (except minor standard changes) should be evaluated to see if the

changes had the desired effect. The effort put into a post change evaluation will be

dependant on the size of the change and the impact it had on the organization (goodor bad, what lessons can be learnt).

- 86 -




Roles

- 87 -




Change Manager

The Change Manger is responsible for:

• Processing of the RFC’s, including filtering, accepting and classifying them.

• Planning, coordinating (with all parties) and the implementation of the Changes.

• Closure of RFC's

• Authorisation, after advice from the CAB or the CAB/EC

• Where appropriate, to obtain authority for Changes to proceed (the level of

authority required will depend on the impact that the change is expected tohave, it's cost and it's urgency).

• To issue the FSC's (Forward Schedule of Changes) via the Service Desk

Change Advisory Board (CAB)

This board should to be made up of representatives from all areas within IT and

representatives from business units. The CAB can have an element of flexibility so if

there are no changes on the Agenda that effect a specific business perhaps they don’t

have to be present at the CAB Meeting.

The CAB assess and plans the major changes.

Change Advisory Board/ Emergency Committee (CAB/ EC)

A sub-set of the CAB that can meet at short notice to consider Emergency changes.

Relationships

The Change Management process depends on the accuracy of the configuration data to

ensure the full impact of making changes is known. There is a very close relationship

between Configuration Management, Release Management and Change Management.

The following diagram illustrates some of the major process relationships.

- 88 -




Advising the Service Desk of changes is crucial. Changes are nearly always first

"discovered" in the Incident Management process, via the Service Desk.

Also the Problem Management process can submit RFC’s to solve Known Errors andsometimes this can cause a snow-ball effect, if the Configuration Management processis unable to explain what the affected components will be as a result of the change

(including hardware, software, SLA's).

Note: SLA's (Service Level Agreements) are discussed in the Service LevelManagement process. It is possible to store information about an SLA in the

Configuration Management Database (CMDB). By doing this relationships canbe created between hardware or software components and the SLA. So when a

change is proposed to a component the linked SLA can be investigated todetermine if the change will breach the SLA.

The others processes are also linked to Change Management in the sense that they

either request changes (Availability Management) or they will be consulted todetermine the impact of changes (IT Service Continuity Management, Service Level

Management and Capacity Management).

- 89 -




Benefits

Change Management is one of the ITIL processes that can often be not really liked. IT

Staff have a tendancy to think that "it's only a small change, no-one will be affected".

It is in these situations that most damage is often done. Discipline is required to

adhere to the process. As an IT support person if you are told to implement the changewithout following the process, ask for the directive in writing, that way there can be no

mis-understanding when problems come up.

Remember that low impact, low risk changes can be covered by creating a change

request that is open-ended and approved. For example, hard disk archiving. Providedthe change is documented, the affected parties listed and the RFC is closed, reviewed

and re-opened on a periodic basis then there is no need to create a seperate RFC

every time the change is required.

The concrete advantages of Change Management are:

• Less impact of changes on the quality of the IT service delivery and the Service

Level Agreements (SLA's).

• Through structured planning, the cost of a change can be estimated more

accurately

• Fewer changes need to be reversed, but if the need arises it is a simpler

process

• Collection of management information is possible on changes.

• Increase in productivity of the user because of a reduction of service

interruptions.

• Increase in productivity of IT staff (less time lost of fixing changes).

Common Problems

Along with the benefits of the any process, we have to acknowledge the inherent

problems as well. Change Management is a highly visible process, both within the ITDepartment and the business users and business customers.

Note: The distinction between Customer and User is straightforward. Thecustomer is the one paying for the service. The User is the ultimate end-user of

the service.

Tool Selection

You need an appropriate tool to support the Change Management process. Ideally, a

single tool will be able to accommodate the activities of a number of ITIL processes.

With Change Management, it would be almost essential that the same tool be used asthe Configuration Management Data Base.

- 90 -




Defining the Scope

If the changes that are controlled by Change Management are too wide (eg it includes

password rests) the workload will become to high and people will try to bypass theprocess.

Commitment

IT staff might be reluctant to follow procedures because Change Management will be

involved in so many aspects. It is important to make the IT Staff aware of the positive

effect the Change Management process will have on the IT Service as a whole. It isalso necessary to ensure that the team designing the process do not over engineer a

solution. Start simple and build up complexity if it's (a) necessary and (b) value-adding.

Metrics

The beauty of all ITIL processes is that they can be measured. Measurement allows

baseline setting and targets to be set for improvement.

Change Management is no different in this regard and the following indicators arecommon for measuring this process.

• Number of Incidents recorded as a result of a change

• Time taken to implement a change successfully

• Number of Changes that required a roll-back

• Number of Urgent/Emergency changes

• Number of RFC's submitted for consideration

• RFC rejection count

• Change back-log • Changes by business unit/areas/department

Best practices

The following list of sites provide some excellent background reading on Change Management.

Interesting websites

• http://www.itil-service-support-management.com/Pages/Service%20support/Change%20management/Change_mgmt.htm

• http://www.itilworld.com/n-america/service-support_changeman.htm

• http://www.infra.com.au/TuDelft.htm • http://www.itil.co.uk/online_ordering/serv_supp_graphs/sschange.htm • http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/ecomm

erce/maintain/operate/rmdotcom.asp • http://www.atlsysguild.com/

- 91 -

http://www.itil-service-support-management.com/Pages/Service%20support/Change%20management/Change_mgmt.htm



http://www.itilworld.com/n-america/service-support_changeman.htm

http://www.infra.com.au/TuDelft.htm

http://www.itil.co.uk/online_ordering/serv_supp_graphs/sschange.htm

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/ecommerce/maintain/operate/rmdotcom.asp


http://www.atlsysguild.com/

http://www.atlsysguild.com/



http://www.itil.co.uk/online_ordering/serv_supp_graphs/sschange.htm

http://www.infra.com.au/TuDelft.htm

http://www.itilworld.com/n-america/service-support_changeman.htm







• Service Support processes = Incident, Problem, Change, Configuration, Release • Service Delivery processes = Service Level Management, Availability, Capacity,

Financial, Continuity

o Service Desk is a function and Security Management has an active part

in all processes.

A major input into the Process is from Change Management either requestinginformation about items that will be affected or advising the status of changed items.

The process starts with the design, populating and implementing of the CMDB(Configuration Management Data Base)

It is the responsibility of Configuration Management to maintain the CMDB. Populatingthe CMDB can be a costly and lengthy exercise depending on the scope of IT

infrastructure that is to be managed and the depth of detail about each item required(automated tools can play a large part here).

The Outputs of the Process are reports to IT management and also the constant

availability of Information that can be supplied from the CMDB to other processes.

- 95 -




ActivitiesThe activities of the Configuration Management process are:

• Planning

• Identification• Control

• Status accounting

• Verification and Audit

Planning:

This includes setting up the process "boundaries" like the goal, scope, objectives,policies, procedures and interaction expected with other processes.

It is the task of the Configuration Manager to determine what can be achieved, at what

cost - balanced against the business requirements. This combination affects the levelof detail and how many C.I.'s will be specified.

Scope:

The scope of the process must be decided. This essentially answers the question:

What will and will not be included within the process? For example some IT

organizations will manage the PABX and phone systems, in this case theseinfrastructure items would be within the scope of the process.

CI Level:

The CI Level refers to the amount of detail that will be captured for each CI. Forexample is a PC considered enough detail or is it necessary to capture the hard disk,

network card and memory details. The decision about the level of detail required

should depend upon how the information will be used. A lot of detail requires extrawork to keep updated, while too little detail defeats the purpose of the process and

does not contribute towards good decision making.

- 96 -




Identification:

The identification activity involves the gathering of all C.I. information within the scope of

the process. C.I. information is gathered either manually and/or by the use of automatedtools. At the time of gathering this data each CI should be labeled for reference and control

purposes.

Note: The labeling of IT Infrastructure can be incorporated into the Security

Management process. Labeling techniques include visible labels, that include

common contact numbers (eg. Service Desk), reference numbers and even hiddenlabeling (security paint that shows up under "black lights" and microchip identifiers

that are not visible to the human eye).

The information gathered will be governed by the scope, C.I. level and attributes decided

upon.

Note: The attributes of a C.I. are the "things" about that C.I. that we want to

record (eg. the attributes of a Personal Computer can be hard disk size,processor type, processor speed, Operating system version).

Values are the quantifiable measurement of attributes (eg. the value of a hard

disk size can be 3Gig or 8Gig, the value of a processor speed can be 1GigaHertz or 10 GigaHertz)

- 97 -




Before gathering any information control procedures and the ChangeManagement process should be in place so that after information is gatheredand populated into the CMDB changes to the infrastructure don’t make itredundant.

Note: The gathering of data can take several weeks or months.

Control

Before the CMDB is populated control procedures should be in place. It is vital that

changes to the CMDB and the CI’s within are only made with the proper authorisation.Procedures need to be set up so that all changes are always documented, for example

with authorized RFC’s. We can start to see the very strong relationship that Changeand Configuration Management share.

Status accounting

Status accounting is the activity that records the current and historical states of a C.I.

so every change to a C.I. is traceable. Status levels can be defined as part of theplanning process (eg. On order, In use, Out of order, Under repair, Retired).

Verification and audit

By conducting regular audits an organization can verify that all C.I.’s are recordedcorrectly.

- 98 -




The first audit should be held right after the CMDB has been implemented to be makesure it is a correct representation of the actually IT infrastructure.

Other times for audits can be after disasters, major changes and following a pre-defined timetable.

The degree of audit will again need to take into consideration the value that will bederived from the audit and the size (and therefore cost) of doing the audit. Partial

audits, spot audit checks are all feasible strategies to "get a feeling" about the level of

C.I. accuracy.

Roles

The Configuration Manager will assist in determining the scope and level of detailrequired in the process, implement procedures for interaction with other processes and

take responsibility for the planning and population of the CMDB.

The Configuration Librarian is the person who controls access to master copies of

software and documentation. Like any librarian the focus is on physical items. Theseitems will be held in the "definitive software library" (DSL).

Note: In small organizations the role of the Configuration Manager and the

Change manager can be combined.

Relationships

As indicated, the IT infrastructure forms the foundation of the IT organization. Allprocesses within ITIL therefore have links with Configuration Management or retrieve

information from the Configuration Management Database.

Change Management and Release Management however, have the closest relationship

to Configuration Management and could even be considered as an integral part of it.

The flow chart shows the relationships between the 3 processes and how the flowsbetween the processes occur at every stage.

- 99 -




Benefits

Some of the benefits that come from implementing Configuration Management include:

• ability to provide Information to the other processes about C.I.’s and the

relationships that exist between them.

• contribution to IT Service Continuity planning

• control of the IT Infrastructure. Knowing where a C.I. is and who’s responsible

for it.

• efficient and effective Problem management

• efficient and effective processing of Changes

• as an insurance that legal obligations are being met

• optimal support on security issues

The following slide restates some of these benefits and introduces some new ones.

- 100 -




Common Problems

Problems that can prevent an effective implementation of Configuration Management

are:

• Level of detail for the CI’s is not right. If the level is too deep too much

information is recorded which will take to much time, money and effort to

maintain. However, if the level of detail is not detailed enough parts of a C.I.can be changed without anyone knowing. This can result in increased incidents

and problems due to the difficulty in tracing the faulty component.

• Urgent Changes. Emergency changes often happen outside normal hours of

operation. There may be no authorized person to record the changes in theCMDB. This can be combated through a solid procedure of post-change

updating. Otherwise the overall reliability of the CMDB is compromised.

• Commitment: There needs to be a firm commitment from Management toimplement this process, as it can be a high activity process. Discipline is

required from IT Staff to ensure that changes to the infrastructure follow theappropriate steps to keep the CMDB accurate.

• Interaction with other processes. As Configuration Management relies on

Change and Release Management to a large degree it is wise to implementthese processes at the same time. Failing to do so might result in a non-reliable

CMDB and an ineffective process.

- 101 -




• Control. There needs to be a process in place that secures the validity of theCMDB. For example users who can purchase software themselves via the

Internet may create incidents that are difficult to solve due to unknownconfiguration changes (the typical "I didn't change anything !!")

Metrics

Key performance indicators

The measurement of the Configuration Management process has many potential KPI's

that can be analysed. To measure the effectiveness of Configuration management,realistic targets should be set. The targets can be changed over time to ensure

improvement of the process.

• Result of audits. Number of unauthorized C.I.’s, C.I.’s not in use

• Number of changes that due to wrong Configuration information cause incidents

or problems

• RFC’s that were not completed successfully because of poor impact assessment,

incorrect data in the CMDB, or poor version control

• The time a change takes from start to finish

• Software licences that have been wasted or not put into use

- 102 -




Other Indicators could include:

• The amount of calls per month that are solved whilst the User is on the phone

using information from the CMDB.

• Reduction in Incidents and problems over time and the change in impact they

have on the business

• Improvement in the time needed to resolve Incident and Problems that can’t be

fixed immediately

• The number of changes to the CMDB per month because of identified errors inthe CMDB.

• Time needed to record a C.I.

Best practices

The CMDB

Most organizations already use some sort of CMDB, in a spreadsheet or paper based.

In most cases the CMDB is based on database technologies, which makes gathering

information more user friendly. Information that can be gathered from a CMDBinclude:

• Information about C.I.'s

• List of C.I.s affected by a scheduled a Change

• All Requests for Change relating to one C.I.

• The history of a particular C.I.

• List of change and problem records associated with a C.I.

• List of C.I.'s affected by a Problem.

A CMDB also contains information on relationships between Incidents, Problems,Known Errors, Changes, Releases and C.I.'s. The CMDB can aid as a support tool in the

creation and on-going maintenance of legal contracts.

Note: Examples of "relationships" that can be defined are:

• Relies on....

o SLA "Provision of Banking Services" relies on Server 2

o SLA "Provision of Banking Services" relies on Printer 9 • Is part of....

o Hard disk 12 is part of Server 2 • Affects....

o SLA "Provision of Banking Services" affects Customer 11

o SLA "Provision of Banking Services" affects Customer 12

- 103 -




• Is linked to... o Banking system is linked to Admin system

• Had ......

o Printer 9 had RFC 0013 applied

o Printer 9 had RFC 0035 applied

An additional bonus is the use of the CMDB to cover the legal aspects associated withthe maintenance of licences and contracts.

The Definitive Software Library (DSL) is a storage place where all software versions arekept secure. New releases will be built on copies of the software from the DSL, not

from the software that is being used in the production environment. The DSL is playsan important part in the Release management process and is discussed in more detail

in that chapter.


• http://www.itilworld.com/n-america/service-support_configman.htm

• http://www.itil-service-support-management.com/Pages/Servicesupport/Configuration management/Configuration_mgmt.htm

• http://www.itil.co.uk/online_ordering/serv_supp_graphs/ssconfiguration.htm

Essential Terms

IT infrastructure:

All parts of importance to the provision of IT services. These include: hardware,

software, network and components, documentation, manuals, procedures, air-conditioning, cooling, organization etc etc. Staff, however, is not a C.I. (according toITIL, many organizations choose to include staff into their CMDB as soon as the

organization is mature enough to handle this).

Configuration item (CI):

The IT infrastructure is built from components. Every component of the infrastructure,

under the management of the IT organization, is called configuration item (C.I.). A C.I.may have any form of complexity or size and may vary from a complete mainframe to,

for instance, a PC as well as a monitor, keyboard or a floppy disk drive.

Attribute:

An attribute is a characteristic that is recorded about a C.I. Examples of this are:identification number, colour, type, size, manager, user, price, depreciation, supplier,

serial number, version, status, etc.

Values:

- 104 -

http://www.itilworld.com/n-america/service-support_configman.htm

http://www.itil-service-support-management.com/Pages/Service%20support/Configuration%20management/Configuration_mgmt.htm


http://www.itil.co.uk/online_ordering/serv_supp_graphs/ssconfiguration.htm

http://www.itil.co.uk/online_ordering/serv_supp_graphs/ssconfiguration.htm



http://www.itilworld.com/n-america/service-support_configman.htm




A value is the quantifiable part of an attribute. (examples of values are "red", "10","E9", "critical")

Links/Relations:

All relationships are normally recorded in a hierarchical structure (such as a parent-

child relation). Other relationships are "is linked to" or "is used by". Theserelationships should be made between C.I.s in the CMDB.

Configuration Control:

Ensures C.I.’s are only changed with the appropriate documentation and that C.I.’s aretracked from procurement to disposal.

Asset Management:

The difference between Asset Management and Configuration Management is that

Asset Management has a list of assets and Configuration Management has a database

with relationships between C.I.s.

Configuration baseline

A Configuration baseline is the configuration of a product or system established at aspecific point in time, which captures both the structure and details of a configuration.

It serves as reference for further activities.

Release Management

Introduction

With the increasing complexity of systems and a greater need for IT organizations toprovide a stable environment, the release of new software and hardware into the business

must be closely controlled. Quite often however a poor release strategy leads to the very

thing that others in the IT organization are working hard to avoid; downtime and loss of

infrastructure stability.

The "Catch 22" however is that there in an ever increasing pressure to “have the release

sooner”, as it will deliver immediate “benefits” to the organization. External forces oftendrive the demand to get the latest hardware of software into production as businessesstrive to be first to market or to help them gain a competitive edge.

- 105 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=546&een=Release_Management&uitklap=546&language=7&linkeen=546&menugroup=%27,%27inzien.asp?var=546%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=546&een=Release_Management&uitklap=546&language=7&linkeen=546&menugroup=%27,%27inzien.asp?var=546%27)




This process within ITIL aims to provide a structured approach to the management of releases into the infrastructure from release planning through to actual installation.

The relationships with Change Management and Configuration Management are key forthis process as all three are very closely related.

Release Management provides the physical management of software and hardware.

Information about the software and hardware components of the IT and theirrelationships with one another are stored in the Configuration Management Database

(CMDB). Release Management manages the planned and applied changes to softwareand hardware in the IT infrastructure.

To support Change Management and Configuration Management, Release Managementutilises the Definitive Software Library (DSL) and the Definitive Hardware Storage

(DHS).

These secured libraries provide the physical storage location of all software

Configuration Items (CI's) (DSL) and spare parts for hardware (DHS).

Software comes in various forms such as source codes, loads, libraries andexecutables. The different versions of the same software held in the DSL have been

through authorisation and quality controls and are used for the construction andimplementation of releases.

Spare hardware held will be dependant on a risk assessment (looking at the assets of

the organization and then the threats and vulnerabilities), as well as third partyinvolvement regarding support contracts (Underpinning Contracts). Changes to the

production hardware environment must flow through to the DHS, so that any held

spares can be compatible with latest production hardware.

Objective

Release Management is the process that "protects" the live or production environment.Protection comes in the form of formal procedures and extensive testing regarding

proposed changes to software or hardware within the production environment.

Note: The use of the term "Production Environment" conjures up images of a

factory or manufacturing facility. However, it is a generic term applied to allareas of infrastructure in use that contribute towards the realization of

organizational objectives.

Note: It is the use of this term Production Environment that probably providesan answer to a question that gets raised a lot regarding the ITIL framework.

Can the (ITIL) framework be used in other business areas, other than IT ?

The answer is most definitely yes. The framework is not a prescriptive set of processes that lack flexibility. They are a set of generic guidelines that, with the

right perspective, can be applied just as easily to manufacturing & engineeringdisciplines.

- 106 -




Objectives of Release Management process include:

• To manage, distribute and implement approved hardware and software items.

• Provision for physical and secure storage of approved hardware and softwareitems in the Definitive Hardware Store (DHS) and Definitive Software Library

(DSL)

• Ensuring that only authorized and quality controlled software & hardware

versions are used in the test and production environments.

Note: Even the test environment can be subject to the ReleaseManagement process. Many businesses have a very high reliance on

their test centres and cannot afford uncontrolled actions, simply because

the environment is not the front line of the business.

Process Description

The main components controlled under a good Release Management process include:

• In-house developed applications,

- 107 -




• Purchased software and custom built software,• Utility applications,

• Software provided by suppliers for use on specialist systems,• Hardware and hardware rollouts

• Instructions and user manuals

Release Management manages all software and hardware from purchase ordevelopment until testing and the eventual migration into production.

The process starts with the planning of a new release, be it for hardware or softwareand ends with a well documented, securely stored, implemented new release with the

lowest possible impact on the organizations day-to-day activities.

The following diagram illustrates some of the basic before and after situations

surrounding the Release Management process.

ActivitiesThe following diagram shows the activities of Release Management and their

relationships with the Configuration Management Database (CMDB):

- 108 -




In a list format the activities described in the picture include:

• Planning and describing the Release Policy of a Release

• The design, building and configuration of Releases

• Testing and signing off of new releases

• Planning the rollout of releases

• Communication, preparation and training

• Release, distribution and the installation

Planning and describing the Release Policy

The Release Policy will document how the organization will approach the release of newhardware and software in to the infrastructure. Specified in this policy will be items

such as:

- 109 -




• The frequency of releases that is acceptable to the business

• A policy on how to issue emergency releases

• A policy on testing and subsequent release into production

• The scope of the Release Management process ie. What level of control andwhat parts of the infrastructure will be under the control of the process

• Naming conventions for releases

Preparation for any release requires a structured planning approach to increase thechance of success. The use of a formal project management methodology like

PRINCE2 will assist in this to define items such as:

• Contents of the Release

• A release schedule

• Resource requirements

• Roles and responsibilities

• Project Approach

• Definition of the release components

• Back up plan

• Quality plan

• Acceptance plan

Note: PRINCE2 is an acronym for PRojects IN Controlled Environments. Like

ITIL PRINCE2 is a methodology or framework, not a tool for ProjectManagement.

PRINCE2 is published by the same body that publishes ITIL (the Office of Government Commerce (OGC) in the UK). And like ITIL it is a widely accepted

framework for best practice.

You can find extra information on PRINCE2 at: http://www.ogc.gov.uk/prince/

The Design, Building and Configuration of Releases

This activity within Release Management can be considered as the technical stage of

the process. All the actions associated with designing, configuration and building arecompleted by relevant staff, in a "controlled" manner.

- 110 -

http://www.ogc.gov.uk/prince/

http://www.ogc.gov.uk/prince/




Note: The term "controlled" is not intended to create an image of bureaucracy.Controlled environments are reproducible and that is the critical issue here.

At the end of this stage a Back-Out Plan should also have been created. Back-Outplans can be aimed at restoring all services to their state before any change OR to

restore as close to the pre-change state as is feasible given the nature of the change.

The suitability and content of the Back-Out plan will be assessed during the Change

Management process.

The output of this activity should be a release complete with instructions on itsinstallation, a test plan and a backout plan.

Testing and Signing-Off of New Releases

Lack of adequate testing is the most common cause of failure of all (changes) releases.

Testing should not only be done on the release expected end result but also on the

implementation activities and the back out procedure.

Representatives of the Business should test for expected functionality. This is referred

to as "User Acceptance Testing" (UAT). IT staff perform technical tests including thetest of the installation (ideally the test staff will not be the build staff).

Each of these stages should be signed off separately.

Release acceptance should be performed in a controlled test environment that can be

reset to known configurations of both software and hardware. These configurationsshould be described in the Release definitions and stored in the CMDB, along with any

other related CI’s.

Planning the Rollout of Releases

The overall release plan that was originally created must now be enhanced withdetailed information on the rollout of the release. This will include:

• Task list and resources needed for the task

• A list of all the CI’s to be installed and decommissioned

• In case of multiple sites: action plans for the separate sites taking local

differences into consideration.

• Communications to all involved (users, IT staff)

• Plans for the release rollout purchases (if any)

• Acquiring hardware and software. The rollout plan should include the

procedures to be followed for their secure storage prior to rollout and themechanisms to trace their deployment during the implementation.

- 111 -




• Scheduling meetings for managing staff and groups involved in the Release.

Communication, Preparation and Training

It is important to communicate with all parties involved in order to increase theacceptance and success of the release. This might involve several meetings/training

sessions with user groups, IT staff and Managers.

The timing of any training and/or communication must be planned in accordance with

the expected actual release date.

The Service Desk is a key area that must be informed about the release, any knownissues (or workarounds) that have been established during testing and generally how

the new release should be supported.

The release plan should be made public in case of a large release so users know whatto expect and when.

Release, Distribution and the Installation

Release Management will be responsible for the process of purchase, storage,

transport, delivery, and hand-over of hardware and/or software.

Distribution and installation are seen as different activities. Often a release will be

distributed and (in the case of software) not "go live" until a log-on script is changedand the release activated.

Following the distribution of the release installation will take place making it availableto the user community.

Release Management must work closely with the other processes (mainly ChangeManagement and Configuration Management) to maximise the success of the release.

The CMDB should be updated with the new Release details and all old C.I.s should bedecommissioned and appropriately marked in the CMDB (retired, decommissioned,

etc.)

Roles

The main role within the Release Management process is that of the ReleaseManager.

This person is responsible for defining and maintaining the definition of the release

policy and controlling the activities within the process. The Release Manager will have a

good technical background and a good knowledge regarding latest utilities and supporttools.

The combination of roles is permissible for certain ITIL processes. In smaller ITorganizations the combination of the Release Manager, Change Management and

Configuration Management processes is realistic.

- 112 -




Release Management staff will need to receive technical training for development,software maintenance and hardware build skills.

Project Management is another essential characteristic that is evident in a ReleaseManagement environment.

Relationships

Release Management is very closely linked with Change Management and

Configuration Management. Change Management controls all the changes anddetermines when a new release will be implemented and what changes will be in any

release. In most major organizations a representative for the Release Managementprocess will have a representative in the Change Advisory Board (CAB).

Note: The CAB is the authorising body for changes to proceed. Can you

remember the term given to the group of people who approve EmergencyChanges?

Configuration Management needs to be informed by Release Management about every

change to a Configuration Item (C.I.) so they can update the CMDB. They also need tomake sure that new versions of software and hardware are being stored in the DSL or

DHS. Release Management will use Configuration Management to get informationabout C.I.'s that may be affected by a new release and importantly their relationship

with other C.I.s.

- 113 -




Benefits

Implementation of the ITIL Release Management process provides the following

advantages:

• Software is being released for testing and production in a controlled manner,

reducing the chance of errors.

• The software (source, loads and executables) of the organization is held in a

secure location (the Definitive Software Library (DSL)).

• Ability to implement many concurrent changes in the software being used in theproduction environment without adversely affecting the quality of the IT

environment.

• Software in remote locations can be managed effectively and economically froma central point.

• The possibility of the use of illegal copies is dramatically reduced.

• The impact of new hardware is tested prior to installation in the infrastructure.

• With end users more informed of new releases and involved in testing the newreleases the risk of resistance will be reduced significantly.

- 114 -




Common Problems

In order for Release Management to be successful the following issues need to betaken in consideration as they may cause problems:

• Lack of Commitment: End Users might be reluctant at first to be told by thisprocess how to act in case of a new release. The advantage of this process

needs to be communicated before the process is implemented.

• Urgent fixes. Procedures need to be in place to make sure that they are dealtwith correctly and don’t compromise the accuracy of the CMDB, DSL or DHS.

• Testing. A proper tests environment needs to be available in order to assess the

impact and reduce the risk of a new release.

• Bypassing of the process my cause illegal software or viruses to enter the IT

Infrastructure. Regular audits can help to minimise this potential issue.

Metrics

In order to assess the effectiveness of the Release Management process a number of

key performance indicators (KPI’s) should be monitored.

- 115 -




Examples of possible indicators are:

• Releases built and implemented on schedule, and within budgeted resources

• Number of Releases that result in a back out due to unacceptable errors

• Number of Incidents caused by the release

• Outcome of audits of the DSL and the DHS. Security - all software can be

accounted for etc.

• Proper use of the DSL for software development

• Compliance with all legal restrictions relating to purchased software

• Accurate and timely recording of all build, distribution and implementation

activities within the CMDB

Best practices

Different Types of Releases

ITIL defines three different release types as described.

Delta release

Includes only those CI’s within the release unit that have actually changed or are new

since the last full or package release. For example: In a word processing package thehelp file has a bug and requires an update. Only the help file module is updated whilst

the rest of the program remains the same. The same analogy could be used with theword processing package as a part of the whole office automation suite.

Full release

In a full release all components of the release are updated. For example: An update

is made to the whole office automation suite including the word processing package,

spreadsheet database etc.

Package release

The Package release includes all previous delta and full releases. These releases are

generally implemented less frequently and therefore allow for longer periods of stability for the live environment. An example of a Package Release might be an SOE

(Standard Operating Environment) for a desktop PC that includes the hardware, officeautomation and business applications.

- 116 -




Types of relevant environments

• Development. Only here can new software be developed. Newer versions will be

based on a copy of the software in the DSL. Each new version will cause anincreased version number.

• Testing. Should be a replication of the live environment in order to reduce risksof the implementation. Developers do not work in this area.

• Production. Where the software/hardware is in production. Developers do not

work in this area.

• Archiving. Old release versions that are no longer in use

I n t e r e st i n g w e b si t e s

• http://www.itil-service-support-management.com/Pages/Servicesupport/Release management/Release_mgmt.htm

• http://www.itil.co.uk/online_ordering/serv_supp_graphs/release_mngt.htm

• http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolution

s/ecommerce/maintain/operate/rmdotcom.asp

- 117 -

http://www.itil-service-support-management.com/Pages/Service%20support/Release%20management/Release_mgmt.htm


http://www.itil.co.uk/online_ordering/serv_supp_graphs/release_mngt.htm





http://www.itil.co.uk/online_ordering/serv_supp_graphs/release_mngt.htm






Essential Terms

Definitive Software Library:

A library, which stores in their definitive, accepted form, all the versions of software

configuration items that have been accepted from the developer or supplier. Thislogical library can be physically present in several locations.

Definitive Hardware Store:

A physical secure storage of definitive hardware spares. These are spare components

and assemblies that are maintained at the same level as the comparative systemswithin the live environment.

Release:

A software CI introduced into the test environment and subsequently into theproduction environment. In most cases documentation and accompanying hardware

also are part of the release.

Release Unit:

A Release Unit includes the CI’s that can be released together.

Type of Releases:

Full Release: all components of a release unit are built, tested, distributed and implemented together.

Delta Release: or partial release, only those CI's in the Release Unit that have actually changed since

the last delta or full release.

Package Release: combination of full releases and delta releases (helps to reduce the risk of

incompatible releases, by changing many systems concurrently).


- 118 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=627&een=Service_Level_Management&uitklap=627&language=7&linkeen=627&menugroup=%27,%27inzien.asp?var=627%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=627&een=Service_Level_Management&uitklap=627&language=7&linkeen=627&menugroup=%27,%27inzien.asp?var=627%27)




Introduction

I m a g i n e t h e f o l l ow i n g s i t u at i o n :

The Managing Director (MD) announces to the Chief Information Officer (CIO) that thecompany is thinking about outsourcing the IT Organization. Over the last two yearsthere have been numerous and major complaints about the current IT services by thebusiness. The customers say it doesn’t do what it should, it is not working properly etc.

The CIO is puzzled to say the least. He had no idea that they were doing so badly.They actually thought they were doing well. The services were up and running for mostof the time. They resolve incidents quickly and didn’t get many complaints from theusers that they were aware of.

His staff have been putting in an enormous amount of effort to upgrade the server thatthe payroll system has been running on.

How could we have done any better?

See the problem?

1. The IT Organization thinks it is delivering services of a high standard but theyhave no figures to back that up. The loosely defined "up and running most of the time" didn't take into account the outages during critical times.

2. The effort on upgrading the server is commendable, but of no benefit as thebusiness recently decided to outsource the company payroll activities.

- 119 -




3. There probably is no official procedure in place to ask for the Customers opinionor a how to make a complaint so how could they have know about theperception of the customer regarding there services?

Implementing the Service Level Management process will solve the main problems in

this situation. The most widely known element of Service Level Management are

Service Level Agreements (SLA's). SLA's allow the IT organization and the customer tocome to agreement about which services are been provided, the availability required of

them and their costs. These levels would be measurable so both sides can verify if thelevels are being met.

Service Level Management is the process that forms the link between the ITorganization and the customers. Implementing Service Level Management can only be

completely successful when the other ITIL processes are implemented as well.

The main aim of SLM is to ensure the quality of the IT services provided, at a cost

acceptable to the business.

Note: There are some who feel that Service Level Management is the single mostimportant process within ITIL. This is a difficult argument to defend. By its very nature

of processes within ITIL are of equal standing. It is true that SLM has more of a'customer focus' than most other processes, but without those other processes, there

is nothing to see the customer about!

Objective

- 120 -




The Service Level Management process manages the quality of IT service deliveryaccording to a written agreement between the users and IT department called the

Service Level Agreements (SLAs).

The goal for SLM is to maintain and improve on service quality through a constant

cycle of agreeing, monitoring, reporting and improving the current levels of service. It

is strategically focused on the business and maintaining the alignment between thebusiness and IT.

Process Description

In order to understand the Service Level Management process it is necessary to

understand some basic concepts that are used, we will be explaining them here so theprocess is easier to understand.

Service Level Requirements (SLR)

This is a document that contains customer requirements regarding which IT servicesthey want and the availability/performance they need for those services. This is the

starting point of setting up the Service Level Agreements.

Service Specifications

The IT organization draws up the Service Specifications based on the SLR. This is the

translation of the customer requirements into "how" the IT organization is going toprovide these services. What are the technical needs? It also will show relationships

between the SLAs, the third parties and IT the organization itself.

- 121 -




Service Level Agreement (SLA)

The SLA is a document that defines agreed service levels between the customer and

provider, i.e. between IT and the business. SLAs should be written in language thatthe business understands (clear, concise and free of jargon). SLAs should not include

detailed procedure diagrams for other processes or content such as technical

information that the business will not understand.

Underpinning Contracts (UPCs or UCs)

With the an external supplier or third party is involved in the delivery of IT Servicesthen a contract has to be drawn up to ensure that they provide their service within a

certain agreed time, cost, level, etc. The IT organization passes through the business

requirements to external suppliers.

This document will be reflective of the service levels defined in SLAs. For example, if

the SLA states a fix of a printer in 5 days then the UC with the third party shouldsupport this i.e. Fix printer and return to organization in 3 days.

Operational Level Agreement (OLA) or Service Provisioning Agreement (SPA)

Some IT services depend on other service being provided from within the ITorganization. For example a service to provide a program that runs via the network

depends on the availability of the network. Agreements about the availability of thenetwork will be drawn up in an Operational Level Agreement or SPA. As with the UPC

these internal "contracts" will support the SLAs in the same manner except the focus istowards the internal IT organization.

Service Quality Plan (SQP)

This plan will contain information about performance indicators for the IT organizationto measure the Services. It will contain performance indicators for each of the

processes that are implemented in the organization. It is important to also include the

performance indicators in the UCs and OLAs as they contribute to the IT service as awhole.

Service Catalogue

This is a document that contains all the Services that are provided, a description of theservice, service levels, cost of the service, the customer and the person/department

responsible for the maintenance of the service. The content of a Service Catalogue willvary depending on the requirements of the IT organization.

Service Specification sheets often form part of the Service Catalog.

Note: Be sure to understand the principal difference between an Underpinning Contractand an Operational Level Agreement.

- 122 -




Activities

The main activities of Service Level Management consist of:

• Composing a Service Catalogue

- 123 -




• Time needed for a change.

• All major disruptions to the IT service in detail.

• Use of the capacity (minimum and maximum)

• Amount of interactions with various services

Reviewing

Reviewing the Service with the Customers on a regular basis will help discover

opportunities to improve the IT service that is provided. With the help of a ServiceImprovement Plan (SIP) this can be achieved.

Once the Service Level Agreements are documented is it not end of the process it isthe start!

It is also important to regularly review how the process itself operates and updatewhere necessary.

Roles

Service Level Manager Role

The Service Level Manager is responsible for the implementing of the process and

maintaining or improving the Service Levels by initiating improvement actions. Therole requires a position that allows the person to negotiate the service levels with the

customers on behalf of the IT organization.

The Service Level Manger oversees the steps that result in the following official

documents:

• Service Level Requirements

• Service Specs

• Service Level Agreement

• Underpinning contract

• Operational Level Agreements

- 126 -




• Service Quality plan

• Service Improvement plan

Relationships

Service Level Management is at once the basis and, the result of, the implementationof Service Management processes. Service Level Management is related to every other

module within Service Management.You can’t implement Service Level Management to a full maturity without the other

nine processes and the Service Desk function, due to the holistic approach required for

Service Management.

The Service Support processes - Incident and Problem and the Service Desk - aim to

restore the services as soon as possible when there is a breach within the ServiceLevels. They provide SLM with valuable information as the customer’s perception of the

Service Levels.

The Service Delivery processes are more focussed on keeping the services runningwithin the parameters defined in the SLAs. They get information from SLM about the

required levels and give information about the actual levels and advice about theimpact of new or changed services.

- 127 -




Note: Remember the Service Support Processes are:

o Incident Management

o Problem Management

o Change Management

o Release Management

o Configuration Management

Benefits

Introducing Service Level Management will have the following benefits for the Businessand the IT organization:

• The IT service will be of a higher quality and will cause less interruption. Hence

the productivity of the IT customers will improve as well.

• The resources of IT staff will be used more efficiently.

• The IT organization will provide services that meet the expectations of the

customers.

• The service provided can be measured.

- 128 -




• The perception of the IT organization will improve.

• Cost reduction.

• The services provided by the third parties is more manageable with theunderpinning contracts in place and therefore any possibility of negative

influence on the IT service provided is reduced.

• Monitoring the service make it possible to identify week spots that can be

improved.

- 129 -




Common Problems

The following issues need to be addressed in order to ensure a successful Service LevelManagement process:

• The service levels set out in the SLAs must be achievable for the IT

Organization in the first place.

• UCs and or OLAs much be set up properly otherwise external suppliers orinternal parties may inadvertently create a breach of the agreed Service Levels.

• The services need to be measurable and objective for IT Customers and the IT

organization.

• There needs to be a commitment to negotiate the Service Levels required and

in the drawing up Service Level Agreements. This must be backed with acommitment to conduct regular reviews and not simply let the agreements get

outdated.

Note: A useful acronym when thinking about Service Level Agreements (or anycontract) is SMART

- 130 -




• Simple • Measurable

• Achievable • Realistic

• Time driven

- 131 -




Metrics

The following question will help determine if the Service Level Management process is

effective and efficient:

• Are all services covered by SLAs?

• Do the services within the SLAs have the necessary UCs and or OLAs?

• Is there an improvement in the Service Levels?

• Are the actual Service Levels measured?

• Is the perception of the IT organization improving?

Best p rac t ices


Assessment

http://www.itil.co.uk/online_ordering/serv_del_graphs/servlevel_mngt.htm

- 132 -






White papers

http://www.interpromusa.com/SLA Challenges for ASPs.pdf

Books

http://www3.gartner.com/1_researchanalysis/focus/entmgmt013002.html

More theory

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/m

aintain/opsguide/cfgmgtog.asp

Essen t i a l s ( t e rm ino logy )

Service Level Management:

The process of negotiating, defining, drafting, securing and revising a demanded and

cost justified level of service delivery to the user.

Service Level Requirements

Business demands and requirements for service levels. Examples are: downtime,availability % and opening hours of the helpdesk. Together with the service catalogue

they can be input for the SLA negotiations.

Service Catalogue

Overview of all current services as delivered by IT. May have a price list attached.

SIP = Service Improvement Program / Plan

Actions, phases and due dates for the improvement of the services

SQP = Service Quality Program / Plan

A document that contains all the information for the managers, including the

Performance Indicators for the other ITIL processes.

- 133 -

http://www.interpromusa.com/SLA%20Challenges%20for%20ASPs.pdf


http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/windows2000serv/maintain/opsguide/cfgmgtog.asp





http://www.interpromusa.com/SLA%20Challenges%20for%20ASPs.pdf




- 135 -




Process Description

Financial Management for IT Services consists of the following three sub-processes:

Budgeting (mandatory)

Budgeting is the process of predicting and controlling the spending of money within the

organization and consists of a periodic negotiation cycle to set budgets (usuallyannual) and the day-to-day monitoring of current budgets.

Budgeting ensures that the correct finance is available for the provision of IT Servicesand that during the budget period they are not over-spent. All organizations have a

periodic (e.g. annual) round of negotiations between the business departments and the

IT organization covering expenditure plans and agreed investment programs whichultimately sets the budgets for IT.

IT Accounting (mandatory)

IT Accounting is the set of processes that enable the IT organization to account fully

for the way its money is spent (particularly the ability to identify costs by Customer, by

service and by activity). It is in this regard more important to understand the coststhan to know up to the dollar cent how much something costs.

Charging (optional)

Charging is the set of processes required to bill Customersfor the services supplied to them. This requires sound IT

Accounting and needs to be done in a simple, fair andaccurate way.

Within organizations there are two distinct cycles

associated with Budgeting, IT Accounting and Charging:

• A planning cycle (annual) where cost projections and workload forecasting forma basis for cost calculations and price setting.

• An operational cycle (monthly or quarterly) where costs are monitored andchecked against budgets, bills are issued and revenue collected.

All these processes are discussed in more detail in the following chapter.

- 137 -




Activities

Each of the three sub-processes of Financial Management for IT Services consist of a

set of activities, which will be discussed in this chapter.

Budgeting

• Determine the budget method:

o Incremental budgeting

Last year’s figures are used as the foundations for this year’s budget

o Zero-based budgeting

A fresh start: Called the Zero base. The purpose and need of every

expense needs to be determined, together with the actual amount.

• Determine the budget period

- 138 -




In most cases this will be the period of a financial (fiscal) year which canwe subdivided in smaller periods.

• Set up the budget

Determine all the categories available and estimate the costs for the

next budget period. Take in consideration that demand might increaseover time. Some costs might need to be estimated.

IT Accounting

IT Accounting aims to provide the information about what the money was spent on. All

Configuration Items necessary to deliver an IT Service to the Customer bear a certaincost. These costs together add up to the total costs necessary for IT Service delivery.

In order to understand costs we need to discuss costs in a general way.

- 139 -




Direct or Indirect costs.

Direct costs are costs that can be assigned to specific services. For example the cost of

a printer that is used by one department only can be seen direct costs. Indirect costsare costs that can’t be related to a certain service. For example the electricity of the IT

department they are also called shared costs.

Capital versus Operational costs

Capital costs are costs involved with the purchasing of items that will be used over afew years and need to be depreciated. (The depreciation amount is part of the total

costs). Operational costs are those resulting from the day-to-day running of the IT

Services organization (e.g. staff costs, electricity, hardware maintenance) and relate torepeating payments whose effects can be measured within a short timeframe (usually

less than 12 months).

Fixed or variable costs

Fixed costs are costs that stay the same regardless. The rent of a building is an

example of fixed costs. Variable costs change with the use of the service. If you take atelephone service as an example the line rental costs are fixed, as they will be the

same each month regardless how many calls you make. The costs for the calls arevariable costs as they depend on the amount of calls are made.

Cost types

Cost types need to be determined (they are also used in the budgeting activity). The

main cost types are Hardware, Software, People, Accommodation, Transfer andExternal Service costs.

Depreciation methods

Capital costs are depreciated over the useful live of the fixed asset (e.g. desktops in

three years, the mainframe in ten years). There are three methods of depreciation:

Straight-line method.An equal amount is written off the value of the asset each year.

Reducing balance method.A percentage of the capital cost is written off the net book value each year.

- 140 -




• Depreciation by usageThe Depreciation is written-off to the extent of usage during a period.

In most cases there already will be an accounting model in place for the rest of the

business. It is important to define a Cost Model that complies with the overall businessaccounting model.

Charging

In a Profit Centre the objective is to recover, through Charging, an amount greaterthan the costs incurred. For an in-house IT organization the aim could be to recover

the costs back in a fair and simple way. But it could also be just to influence the

behaviour of the Customers and end users. That is, via Charging the IT organizationcan influence the demand and actual usage of IT Services, and the way the service are

provided.

Before Charging can take place a few decisions need to be made regarding the

Charging policy, Cost Units and Pricing.

A Charging policy needs to be chosen:

Communication of informationOnly the actual costs will be calculated, reported and charged to the customer (plusspecific amounts, if this is agreed with the customer).

- 141 -




Pricing flexibilityEstablish and charge the prices each year. This method gives the option to influence

excessive use.

Notional chargingAll costs are invoiced, but the customer doesn’t have to pay the physical dollars. This

method is used to gain experience and eliminate mistakes.

In order to be able to charge the costs to the IT customers Cost Units or chargeable

items need to be set up. These have to be clear, so they can be checked and areunderstood by the Customer. Examples would the PC they use, the amount of print

jobs they request.

Pricing moves the budget responsibility from the IT department to the user

organization. A good pricing system gives the client the sense that they get value fortheir money.

A pricing method (or a combination) need to be chosen:

Cost price

Cost price plus (to cover expenses made for R&D and overhead)

Market prices, the price that is charged for the service on an outside market

Going rate. Rate that is also used in similar organization or other departments within

the business.

Fixed price. The price is negotiated with the customer beforehand

- 142 -




Roles

The IT Finance Manager can be a person from the IT organization or the Finance

department. An alternative would be that the tasks, associated with this role, areshared between both. The main responsibilities are:

• To oversee the implementation of the Financial Management for IT Services

process and their sub processes (Budgeting, IT Accounting and Charging).

• Assist in setting up the budgets and the accounting plans.

• To work, at an appropriate level, with representatives of the organization

management and the Finance Department, to develop the policies of Budgeting,IT Accounting and Charging.

If the IT Finance Manger is from the IT organization maintaining a close relationshipwith the Finance Department becomes one of the responsibilities.

- 143 -




Relationships

Financial Management for IT Services provides (depending on which pricing system has

been chosen within the organization), important information to Service LevelManagement about the introduced costing, pricing and charging strategies.

As well as this the Financial Management process analyses which level of service

delivery is technically cost realistic for the business.

Financial Management for IT services can, together with Capacity Management andAvailability Management, develop pricing strategies. These strategies can realise an

optimal spread of the workload within an organization, which will result in optimal use

of resources. It can also use asset and cost information from ConfigurationManagement to analyse different scenarios of equipment (different costs for different

configurations).

Benefits

The benefits of implementing the Financial Management for IT Services process

include:

• Increased confidence in setting and managing budgets.

• A more efficient use of IT resources throughout the organization.

• Higher satisfaction of Customers as they know what they are paying for.

• Investment decisions can be made on accurate information.

• Increased professionalism of staff within the IT organization.

Divided per sub process the benefits will be:

For budgeting:

• Ability to estimate the total costs needed to run the IT organization.

• Reducing the risk of spending more money then is available.

• The ability to verify if the actual costs compare to the estimate costs.

- 144 -




• The guarantee that the money resources are available to run the ITorganization within the agreed Service Levels.

For IT Accounting:

• Availability of management information on the costs of providing IT Services.

• IT and Business managers make better decisions, which ensures that the ITServices organization runs in a cost-effective manner.

• Ability to accurately account for all the expenses made by the IT organization.

• Demonstrate under- or over-consumption of services in financial terms.

• Maximising the value for money of the provided IT services.

• The possibility to determine the costs of NOT making a specific investment.

• Form the basis to implement Charging.

For Charging:

• Providing a sound business method of balancing the shape and quantity of IT

Services with the needs and resources of the Customer.

• The ability to recover IT costs in a fair manner.

• Influence the demand for the provided IT Services; hence influence the

behaviour of the Customer.

Common Problems

In order for the process to work effective and efficiently the following issues should beaddressed as they are typical areas that can cause problems in this process area;

• Cost Models that are used for IT Accounting are too detailed, creating too much

administrative overhead.

• Not enough commitment from senior IT and Business management.

- 145 -




• Financial Management for IT Services is not in alignment with the way theoverall organization manages its finances.

• Charging policies are not well communicated to customers possibly causingunwanted behaviour (eg. actions by users/customers to try to avoid incurring

charges).

Note: The area of Financial Management for IT Services is often glossed over. Typically,customers agree to charges at a point in time, but when the actual charges are levied the

challenges begin. To offset this, it is wise to quite often ensure that your customer has had

their expectations set, so that levied charges do not come as a shock.

Metrics

Key performance indicators to report on the process are:

• Accurate cost–benefit analysis of the services provided

• Customers consider the charging methods reasonable

• The IT organization meets its financial targets• The use of the services by the customer changes

• Timely reporting to Service Level Management

- 146 -




Other issues that can be reported on are:

• Creditor / Debtor management

• Other specialised accounting measurements (eg. liquidity of assets)

Note: Accountancy is a respected profession around the world. It is very unlikely that this

process can be properly implemented without some specific expertise in accounting.

Best practices


Assesment

http://www.itil.co.uk/online_ordering/serv_del_graphs/financial_mngt.htm

White paper

http://www.interpromusa.com/IT Cost Charging Challenges.pdf

More theory

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/wi

ndows2000serv/maintain/opsguide/cfgmgtog.asp

Essen t i a l s ( t e rm ino logy )

Financial Management for IT services:The implementation of Financial Management for IT services is the foundation for an

- 147 -


http://www.interpromusa.com/IT%20Cost%20Charging%20Challenges.pdf





http://www.interpromusa.com/IT%20Cost%20Charging%20Challenges.pdf






IntroductionOrganizations are increasingly dependent on IT services, when they are unavailable,

in most cases the business stops as well. There is also an increasing demand for 7days per week 24 hrs a day availability of IT services.

It is therefore vital for the IT organization to manage and control the availability of the

IT Services. This is done by defining the requirements from the business regarding theavailability of the IT services and then matching them with the possibilities of the IT

organization.

Objective

The objective of Availability Management is to get a clear picture of businessrequirements regarding IT Services availability and then optimize infrastructure

capabilities to align with these needs.

- 149 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=651&een=Availability_Management&uitklap=651&language=7&linkeen=651&menugroup=%27,%27inzien.asp?var=651%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=651&een=Availability_Management&uitklap=651&language=7&linkeen=651&menugroup=%27,%27inzien.asp?var=651%27)




Or one can put it this way:

To ensure the highest availability possible of the IT services as required by the

business to reach its goals.

Process Description

Availability Management depends on a lot of inputs to be able to function well.

Among the inputs are:

• The requirements regarding the availability of the business

• Information regarding reliability, maintainability, recoverability andserviceability of the CI’s

• Information from the other processes, Incidents, Problems, SLAs and achievedservice levels

The outputs of the process are:

- 150 -




• Recommendation regarding the IT infrastructure to ensure the resilience of theIT infrastructure

• Reports about the availability of the services

• Procedures to ensure availability and recovery are dealt with for every new or

improved IT service.

• Plans to improve the Availability of the IT services

Key terminology and actions that form the basis of this process are:

Availability: The availability and flexibility of components of the infrastructure. This is expressed inthe following formula:

A = (ST - DT)/ ST x 100, whereby A - Availability, ST = agreed Service Time and DT

= Down Time.

Availability is defined as:

“Availability of a IT Service or component to perform its required function at a statedinstant or over a stated period’ (ITIL Service Delivery Book, OGC,2001)

Reliability: The reliability of components of the infrastructure. In this case the Mean Time Between

Failures (MTBF) can be used as a measuring tool.

Reliability is defined as:

“…freedom from operational failure” (ITIL Service Delivery Book, OGC, 2001)

Resilience is a key aspect of reliability

Resilience is defined as:

“The ability of an IT component to continue to operate even though one or more of itssub components has failed”

Maintainability: The capability to maintain or restore a service or component of the infrastructure at a

certain level, so that the required functionality can be delivered. Some services orindeed components of the infrastructure are easier to maintain and/or restore to

service in the event of a failure. For example, an application has been developed thatrequires daily housekeeping to ensure its operation and a highly qualified Database

Administrator can only do this. This application is not easy to maintain. The

maintainability of C.I.'s within the infrastructure is an important consideration as the

- 151 -




speed of recovery and the ease of maintenance will impact the uptime and henceavailability of services.

Operational Level agreements (OLA's) within the Service Level Management process tiein here.

Note: Remember that C.I. = Configuration Item

Serviceability: Serviceability refers to the agreements that are held with third parties providing

services to the IT organization. These contracts will define how these external partieswill perform to ensure the availability of the services they interface with. For example,

how will they ensure resilience, how will they maintain the infrastructure they areresponsible for.

Underpinning Contracts within Service Level Management tie in here.

Security:

This is divided into confidentiality, integrity and availability (CIA). It can be desirable(for security reasons, which might endanger the availability) not to make certain

components of the infrastructure available, logically or physically.

Security is of great concern to most organizations these days and it is important toensure that IT services are made available to the organization in a secure way. That

means that services and information is available to the right people. It is alsoimportant to ensure that services are not so secure that it impedes that ability of the

organization to use these services.

- 152 -




Activities

The activities within the process can be divided in three main activities, which will be

discussed in detail in the remainder of this chapter:

• Planning

• Improving

• Measuring and reporting

Planning

Planning involves the following activities:

Determine the Availability Requirements

It is important not only to find out the requirements but also to find out if and how theIT organization can meet these requirements. The Service Level Management process

maintains contact with the business and will be able to provide the availability

expectations to the Availability Management process. The business may have unrealisticexpectations with respect to availability without understanding what this means in real

terms.

- 153 -




Improving

Developing the Availability Plan

The Availability Plan will look into the future (for example 12 months) and documentwhat measures will be put in place to ensure that the infrastructure and IT services will

be available to meet business requirements.

Input from monitoring and other processes, such as Service Level Management, will

provide the basis for decisions on what “availability” measures will be put in place. All

plans must be cost justifiable and aligned with business needs.

Measuring and reporting

This involves reporting about the availability of each service, the down times and

recovery times. These reports will often go to the Service Level Management process

to use in reporting comparisons (planned versus actual) on service levels back to thecustomer.

It is also important to measure and report on the perception of the customers on theavailability of the IT service.

You can use many ways to identify (un-) availability and potential problems. Thefollowing are a few mentioned by the OGC:

CFIAComponent Failure Impact Assessment can be used to predict and evaluate the impact

on IT Service arising from component failures within the IT infrastructure.

FTAFault Tree Analysis is a technique that can be used to determine the chain of events

that causes a disruption to IT services.

CRAMMCCTA Risk Analysis and Management Methodology can be used to identify new risks

and provide appropriate countermeasures associated with any change to the businessavailability requirements and revised IT infrastructure design.

SOA

Systems Outage Analysis is a technique designed to provide a structured approach to

identifying the underlying causes of service interruption to the user.

- 155 -




- 157 -




Benefits

The main benefit is:

Optimal use of the capability of the IT Infrastructure and delivering the availability of

the IT services that is according the agreed requirements of the customers.

Other benefits include:

• Constant striving to improve the availability

• Higher Customer Satisfaction

• In case of a disruption corrective action will be undertaken

• Higher availability of the IT service

- 158 -




Common Problems

As with every process there are some issues that need to be addressed as they can

make or break the success of the process.

For Availability management they are:

• Unclear requirements from the business regarding the availability expected of

the IT service

• No official contract is drawn up to specify the agreed availability of each service.(Risk of conflict and arguments at a later stage)

• Commitment to the process

The business and the IT organization must share a common understanding on thedefinition of availability and the definition of downtime.

- 159 -




Metrics

By reporting on the following items the effectiveness and efficiency of the process can be

measured:

• The total downtime per service

• Time it takes to recover from an incident

• The availability of the services

• The improvement of the availability of the IT services

Note: Check the AV Essentials section for defined availability terms (eg. MTBF, MTTR,

etc.)

Best practices


Assesment

http://www.itil.co.uk/online_ordering/serv_del_graphs/avail_mngt.htm

Essentials (terminology)

- 160 -






Down time:

The total period during which an IT service is not operational within the agreed service

times.

Mean Time Between Failures (MTBF):

The average period between the first moment the service is fully operational and the

moment that this service is no longer operational.

Mean Time To Repair (MTTR):

The average period between commencement of an incident and its solution.

Mean Time to Restore Services (MTRS):

The average period between the commencement of an incident and the restoration of the

service delivery.

Fault, Failure:

The moment at which a functional unit no longer provides the required function.

High Availability

A characteristic of the IT Service that masks the effects of IT component failure to the user.

- 161 -




Continuous Operation

A characteristic of the IT operation that masks the effects of planned downtime to the user.

Continuous AvailabilityA characteristic of the IT Service that minimises or masks the effects of all failures andplanned downtime to the user.

Capacity Management

Introduction

The Capacity Management process is designed to ensure that the capacity of the ITinfrastructure is aligned to business needs.

The main purpose of Capacity Management is to understand and maintain the requiredlevel of service delivery (via the appropriate capacity) - at an acceptable cost.

Through gathering business and technical capacity data this process plans for and

delivers the, cost justified, capacity requirements of the business. The Capacity plan isthe core document that describes how this will take place over the coming period.

- 162 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=664&een=Capacity_Management&uitklap=664&language=7&linkeen=664&menugroup=%27,%27inzien.asp?var=664%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=664&een=Capacity_Management&uitklap=664&language=7&linkeen=664&menugroup=%27,%27inzien.asp?var=664%27)




Objective

The main objective of Capacity Management is to understand the business’s capacity

requirements and deliver against them both in the present and the future.

Capacity Management is also responsible for understanding potential advantages newtechnology could have and assessing its suitability for the organization.

Process Description

The Capacity Management process breaks down into three sub-processes listed below:

- 163 -




Business Capacity Management

This sub process has the focus on the long term. It is responsible for ensuring that the

future business requirements are taken into consideration then planned andimplemented as necessary.

Service Capacity Management

Is responsible for ensuring that the performance of all current IT services falls within

the parameters detailed as targets within SLA’s.

Resource Capacity Management

Is responsible for the management of the individual components within theinfrastructure. Resource capacity management has more of a technical focus.

- 164 -




Activities

Each of the sub process mentioned before involve, to a higher or lesser degree, the

following activities:

• Iterative Activities

• Storage of Capacity Management Data

• Demand management• Application Sizing

• Modeling

• Capacity Plan

• Reporting

- 165 -




Iterative Activities

The following iterative activities take place within Capacity Management:

• Monitoring; checking if all the service levels are being met.

• Analysis; the data collected by monitoring needs to be analysed and predictions

been made for the future• Tuning; implement the outcomes and results of the 2 previous steps to ensure

optimal use of the infrastructure for now and in the future.

• Implementation; to actual implement new capacity or changed capacity withChange Management.

Storage of Capacity Management DataThe Capacity Database (CDB) is the cornerstone of the process. It is used to form the

basis of the reports for this process and contains technical, business and relevantinformation for capacity Management. As well, the information contained here provides

the other processes with the data necessary for their analysis.

Demand management: Demand Management is responsible for the management or workload in the

infrastructure to better utilise the current capacity rather than increasing capacity.User behaviour is influenced to shift workload, for example to another time of the day

to relieve capacity shortages.

Application Sizing: Application Sizing related to the assessment of the capacity requirements of

applications during their planning and development. The capacity requirements of a

new application will be understood and the infrastructure can be tuned as necessary tomeet the new requirements.

Modeling: By simulation or with assistance of mathematical models modeling allows for theprediction of future capacity requirements. The results from this can be used as an

input into the Capacity Plan.

Capacity Plan

Capacity Plan, this plan is drafted on the basis of data from the CDB (Capacity

Database), financial data, business data, technical data, etc. The plan is futureoriented and covers a period of at least 12 months.

Reporting

Reporting entails the reporting of capacity performance over any given period.

Reporting for example could be (but not limited to) against the capacity metrics in

SLAs.

- 166 -




Roles

The Capacity Manager

The main responsibilities of the capacity manager are:

• To develop and maintain the Capacity plan

• Manage the process

• Make sure the Capacity database is up to date.

To do this, the manager must be involved in evaluating all changes, to establish the

effect on capacity and performance. This should happen both when changes areproposed and after they are implemented. They pay particular attention to the

cumulative effect of changes over a period of time. The cumulative effects of singlechanges can often cause degraded response times, file storage problems, and excess

demand for processing capacity.

Other roles within Capacity Management are the roles of the network manager,application and system manger. They are responsible for translating the business

requirements in to required capacity to be able to meet these requirements and tooptimize the performance.

- 167 -




Relationships

Capacity Management is part of Service Delivery and is directly related to the business

requirements. It is not simply about the performance of the system’s components,individually or collectively.

Service Desk, Incident Management and Problem Management.

These processes will provide Capacity Management with information about incidents

and problems related to Capacity. Capacity Management will support the processeswith solving the incidents and or problems and also provide them with information

about the capacity performance.

Change Management and Release Management

Capacity Management activities will raise Request for Changes (RFC's) in order toensure that the appropriate capacity is available. These are subject to the Change

Management process, and implementation may affect several Configuration Items(C.I.'s), including hardware, software and documentation, and will require effective

Release Management.


The link between Capacity Management and Availability Management is strong, as the

availability that is needed requires a certain amount of capacity within theconfiguration items. Without enough capacity, you will never have enough availability.

Furthermore, the values measured by Capacity Management are of importance to

Availability Management in relation to availability and reliability.


Both Capacity Management and Availability Management need to provide the servicelevel manager with input for effective SLA negotiations. Capacity Management informs

Service Level Management about the result levels that can be provided to the client.

Financial Management

The drafted capacity plan delivers important input for Financial Management, which onthis basis can draft a very accurate investment plan capacity Management gets

information in return about the available budget.

IT Service Continuity Management

Capacity Management provide ITSCM with the information about the minimum

required Capacity needed for recovery. It is important to consider the impact (forneeded capacity) of changes to the IT services on the ITSCM procedures.

- 168 -




- 169 -




Common Problems

Common problems that can be encountered while the process is already implemented

include:

• Capacity information from suppliers is not available or is too general and can be

misleading for infrastructure components.

• The expectation to what Capacity Management can do is over estimated. If anapplication is poorly designed, more capacity won’t fix the problem.

• The detail of monitoring can be to deep causing the process to be tooexpensive.

• Information is difficult to obtain. It is not always easy to predict what future

capacity is required before you build an application.

Note: This final point is important. All too often end users and customers areinterviewed at length about their expected capacity requirements, only to demand

more as soon as the new application goes live. It is up to the IT professionals to havebuilt in the ability for the application to scale to match any new requirements.

- 171 -




Metrics

To verify if the process is operating within it goals one should check:

• If the forecast is in line with the actual demand at that time?

• If the Capacity plan is correct?

• Are the requirements being met?

• Is capacity not a cause for the breach of Service Levels, Incidents or Problems?

• Are ad hoc expenses being reduced because better planning is in place?

• Performance against SLAs

- 172 -




Best practices

Why a Capacity Plan?

With cheap hardware prices, capacity planning may seem unimportant; you can alwaysupgrade later. A simple guess of the capacity requirements should be sufficient, right?

Why give this subject any more thought?

There are two main issues that make capacity planning critical.

The first is the rate of technical change. We now measure progress in "Internet years"-- equivalent to about 90 days of a calendar year.

The second is with Internet/Intranet at the helm. Today’s systems are primarily being

developed within a 3-tier architecture. This rapid change, coupled with the increase incomplexity of 3-tier architecture, is causing system designers to pay closer attention to

capacity. Five years ago, a designer could roll out a new system with a rough estimate

of capacity and performance. The system could then be tuned or more capacity addedbefore all of the users had been converted to the new system. The process was

reasonable because the systems were typically not mission-critical.

Today, there’s no time for this approach. Once systems are in place they become anintegral part of the overall design. Downing the system for upgrades becomes

increasingly expensive in both time and resources. In addition, the added complexityof the environment typically requires more care, due to the interdependency between

various application components.

Capacity planning is driven purely by financial considerations. Proper capacity planningcan significantly reduce the overall cost of ownership of a system. Although formal

capacity planning takes time, internal and external staff resources, software andhardware tools, the potential losses incurred without capacity planning are staggering.

Lost productivity of end users in critical business functions, overpaying for networkequipment or services and the costs of upgrading systems already in production more

than justify the cost of capacity planning.


http://www.capacityplanning.com/

Assessment

- 173 -






http:/ / ww w.itil.co.uk/ online_ordering/ serv_del_graphs/ capacity_mngt.htm

White Papers

http://www.interpromusa.com/ASPs and Application Performance Mgmt.pdf

http:/ / www.iccmforum.com/ iccm.asp?r=Capacity&s=CPUResource

Tools

http://regions.cmg.org/regions/cmgarmw/shortarm.html

http://www.iccmforum.com/iccm.asp?r=Tutorial&s=Benchmarks&t=Standard

http://www.iccmforum.com/iccm.asp?r=Tutorial&s=Benchmarks&t=ZiffDavis


Capacity Plan,

A plan that is drafted on the basis of data from the CDB, financial data, business data, technical data, etc. The

plan is future oriented and looks forward for a period of at least two years.

Performance Management

This is the monitoring of results, signaling of trends, analysis of information and tuning (e.g. by spread of

workloads).

Workload Management

The identification and registration of use of resources of each workload and the detection of peaks and

patterns.

Resource Management

The optimization of the use of resources.

- 174 -

http://www.itil.co.uk/online_ordering/serv_del_graphs/capacity_mngt.htm

http://www.interpromusa.com/ASPs%20and%20Application%20Performance%20Mgmt.pdf

http://www.iccmforum.com/iccm.asp?r=Capacity&s=CPUResource







http://www.iccmforum.com/iccm.asp?r=Capacity&s=CPUResource

http://www.interpromusa.com/ASPs%20and%20Application%20Performance%20Mgmt.pdf

http://www.itil.co.uk/online_ordering/serv_del_graphs/capacity_mngt.htm




IT Service Continuity Mgt

Introduction

There are still quite a few managers that see IT Service Continuity Management

(ITSCM) as a luxury for which they do not have to allocate any resources. However,statistics show that disasters regularly occur. Causes of such disasters are events like

fire, lighting, flood, burglary, vandalism, power failure or even terrorist attacks.Thinking about - and actually establishing - a Business Continuity Plan could have

saved affected companies a lot of troubles or even their business itself.

As businesses are becoming increasingly dependent on IT, the impact of theunavailability of IT Services has drastically increased. Every time the availability or

performance of a service is reduced, the users cannot continue with their normal work.This trend towards dependency on IT will continue and will increasingly influence

users, managers and decision-makers. That is why it is important, that the impact of a

total or partial loss of the IT Services is estimated and Continuity Plans established toensure that the business will always be able to continue.

- 175 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=677&een=IT_Service_Continuity_Mgt&uitklap=677&language=7&linkeen=677&menugroup=%27,%27inzien.asp?var=677%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=677&een=IT_Service_Continuity_Mgt&uitklap=677&language=7&linkeen=677&menugroup=%27,%27inzien.asp?var=677%27)




Objective

The objective of the ITSCM process is to support the overall Business Continuity

Management (BCM) process by ensuring that the required IT technical and servicesfacilities can be recovered within required and agreed business time-scales.

Process Description

ITSCM is concerned with managing an organization’s ability to continue to provide a pre-determined andagreed level of IT services to support the minimum business requirements, following an interruption to the

business. This includes:

• Ensuring business survival by reducing the impact of a disaster or major failure.

• Reducing the vulnerability and risk to the business by effective risk analysis and risk management.

• Preventing the loss of Customer and User confidence.

- 176 -




• Producing IT recovery plans that are integrated with and fully support the organization’s overall

Business Continuity Management (BCM) Plan.

ITSCM should be closely aligned with and driven by the overall BCM process, as a sub-

set of this process. BCM manages risks to ensure that the organization can continue tooperate at a specified minimum level in case of a disaster. ITSCM is focused on the IT

Services and ensures that the minimum of IT Services can be provided in case of disaster. One won’t work with out the other.

If the BCM process has a solid plan to evacuate part of the business process andcontinue to work in a separate building, but there is no IT infrastructure ready, theplan is of no use. The same apply if you do have plans which enable the ITorganization to provided the IT Service elsewhere if the business process can’t becontinued because there’s is no contingency plan in place for that.

The process can be divided in 4 stages, which will be described in the next chapter in detail:

• Initiation

• Requirements and strategy

• Implementation

• Operational Management

- 177 -




Activities

Each of the stages has its own activities, which will be described in more detail throughout

this chapter.

Initiation

• Initiate BCM

The initiation process covers the whole of the organization. The policies around BCM

and ITSCM are defined, the scope of the process and the terms of reference

determined, resources allocated and a project plan established.

Requirements and strategy

• Business Impact Analysis

- 178 -




• Business Continuity Strategy

An appropriate strategy needs to be developed with contains an optimal balance of riskreduction and recovery options. The actual balance will very much depend on the

nature of the business and the dependency on IT Services (e.g. a stockbroker willfocus on risk reduction, while the local bakery can probably afford the time involved inrecovering a failed system).

In case of a Recovery Plan decisions have to made on how to recover. The options are:

o No contingency.This choice can be made if a risk analysis suggests that the failure of (a

part of) the IT service delivery does not irretrievably affect business. It

may be sensible however, to confirm in writing, that in case of acalamity no concrete contingency plan is available.

o Administrative procedures.If the infrastructure is no longer available, a switch is made to

administrative procedures. Disadvantage is, that when the availability of

the IT infrastructure is restored a catch-up activity must be performed.

o Fortification strategy.In this approach, one chooses a security method where, in fact, nothingcan happen. The costs of such are high and if, despite this, something

does go wrong, no alternatives are available.

o Reciprocal agreements.In the case of a calamity, organizations make (parts of the)

infrastructure available to each other. Disadvantage is reciprocaldependency and confidentiality of data.

o Gradual Recovery (Cold stand-by) permanent or portable. In this strategy the organization itself has a space available with

infrastructure such as electricity, telephone connections and air-conditioning, where appliances can be "brought in", after which the

service level can be restored. This space could also be located or erected

on site (Porto cabin).

o Intermediate Recovery (Warm stand-by) internal/external/mobile. In this scenario a completely fitted evacuation facility is available, hired,

or brought in. Examples are the Computer Evacuation Centre or the IBMtruck. The last option is only feasible for mid range systems. The internal

warm start means having an evacuation facility available within theorganization.

o Immediate Recovery (Hot stand-by). This is normally an extension of the Intermediate Recovery optionsprovided by third party suppliers. This usually covers extremely critical

services that can affect the survivability of the organization or, at least

- 180 -




such an impact that would stop the organization from making money orother significant long-term effects.

Implementation

• Organization and implementation planning

Several plans need to be set up in order to be able to Implement the ITSCM process.These plans address issues like, emergency procedures, damage assessment, what to

do with data, recovery plans etc.

• Implement stand-by arrangements and risk reduction measure

The risk reduction measures need be implemented. In most cases this will be done

with help of the Availability process. Also stand-by procedures will have to be put inplace. For example setting up an agreement with a third party to supply goods in case

of a disaster without having to go through the proper channels.

• Develop ITSCM plans and procedures

The Recovery Plan (or Continuity plan) has to be set up. The plan should cover at leastthe following subjects:

o How it is going to be updated

o Routing list to specify which section has to go to which group?

o Recovery initiation

o Specialist sections to cover the actions and responsibilities of thesesections individually. Sections are Administration, IT infrastructure,

personnel, security, recovery sites and restoration.

• Perform initial testing

Testing is a critical part of the overall ITSCM process and is the only way of ensuringthat the selected strategy, stand-by arrangements, logistics, business recovery plans

and procedures will work in practice.

Operational Management

- 181 -




• Education, training and awareness

These are essential issues that need to be taken care of in order for the ITSCM process

to be successful. This ensures that all staff are aware of the implications of BusinessContinuity and of IT Service Continuity and consider these as part of their normal

working routine and budget.

• Review and audit

It is necessary to review and audit the plans on a regular basis to make sure they arestill up to date.

• Testing

By testing on a regular basis not only can the effectiveness of the plan be tested butalso people will know what happens, where the plan is and what is in it.

• Change Management

Following tests and reviews and in response to day-to-day Changes, there is a need for

the ITSCM plans to be updated. ITSCM must be included as part of the ChangeManagement process to ensure that any Changes to the IT infrastructure are reflected

in the contingency arrangements provided by IT or third parties.

• Assurance

The quality of the process is verified to assure that the business requirements can bemet and that the operational management processes are working satisfactorily.

Roles

A distinction can be made in roles and responsibilities in and outside crisis times.Different levels within this process can be defined, starting with the board followed by

senior management, management, team leaders and their team members. It is vital todocument the responsibilities of each and every role.

The main responsibilities of the ITSCM manager include:

- 182 -




• Develop and manage the ITSCM Plan to ensure that, at all times, the recoveryobjectives of the business can be achieved.

• Ensure that all IT Service areas are prepared and able to respond to aninvocation of the Continuity Plans.

• Maintain a comprehensive IT testing schedule.

• Communicate and maintain awareness of ITSCM objectives within the business

areas supported and the IT Service areas.

• Manage the IT Service delivery during times of crisis.

Relationships

ITSCM has a close relationship with all the other ITIL processes and the business ingeneral. The relationship with some of the processes is described in more detail.


Service Level Management provides the ITSCM process with information about therequired service levels.


Availability Management has more a supportive role and helps the ITSCM process toprevent and reduce the risk of disasters by delivering / implementing risk reduction

measures.

Configuration Management

Configuration Management provides information about Configuration Items that are

needed in order to be able to restore the IT service after a disaster.

Change Management

Change Management needs to make sure that the ITSCM is aware of the impact of the

Changes on the Continuity and Recovery Plans, so the plans are updated if necessary.

Capac i ty Managem ent

Capacity Management makes sure the appropriate infrastructure can support the

business requirements.

- 183 -




Serv i ce Desk & I nc i den t Management

Service Desk in combination with Incident Management provides the ITSCM process with

historical data (statistics).

Benefits

- 184 -




ITSCM supports the BCM process and delivers the required IT Infrastructure andServices to enable the business to continue to operate following a service disruption.

The main benefits of implementing the ITSCM process are:

• Management of risk and the consequent reduction of the impact of failure.

• Potentially lower insurance premiums

• Fulfillment of mandatory or regulatory requirements

• Improved relationships between the business and IT through IT becoming morebusiness focused, and more aware of business impacts and priorities.

• Increased Customer confidence, possible competitive advantage and increased

organizational credibility.

In case of an actual disaster the process has the following benefits:

• Reduced business disruption, with an ability to recover services efficiently inbusiness priority order.

• Recovery will take place in less time

• More stable IT infrastructure and a higher availability of the IT Services

- 185 -




Common Problems

A few of the problems one can encounter while implementing the ITSCM process are:

• Not enough resources to set up and run the process properly.

• The ITSCM is not based on the BCM.

• No enough commitment from senior IT and business management.

• Overlooking critical components, applications, and dependencies, andmisinterpreting business impacts.

• Recovery isn’t working,due to lack of testing.

• Lack of awareness and support of the users and the IT personnel causing the

process to fail in case of a disaster.

- 186 -




Metrics

During normal operation one can report on:

• The results of testing the plan

• Costs of the process

During/after a disaster one can report on:

• Weaknesses in the plan

• Time that it took to recover versus estimate time

• Losses due to the disaster

Best practices


http://www.globalcontinuity.com/

http://www.microsoft.com/technet/itsolutions/idc/oag/oagc20.asp

http://www.iccmforum.com/iccm.asp?r=Tutorial&s=Benchmarks&t=ZiffDavishttp://www.disasterrecoveryw

orld.com/

Whitepages

http://www.interpromusa.com/IT Service Continuity Mgmt.pdf

Assesment

http://www.itil.co.uk/online_ordering/serv_del_graphs/itserv_cont.htm

- 187 -




http://www.disasterrecoveryworld.com/


http://www.interpromusa.com/IT%20Service%20Continuity%20Mgmt.pdf



http://www.interpromusa.com/IT%20Service%20Continuity%20Mgmt.pdf










Business Continuity Management (BCM)

BCM is concerned with managing risks to ensure that at all times an organization cancontinue operating to, at least, a pre-determined minimum level. The BCM processinvolves reducing the risks to an acceptable level and planning for the recovery of

business processes should a risk materialise and a disruption to the business occur.

IT Disaster The unavailability for a longer period of time of IT Service provision which makes in

necessary to switch to an alternative system and for which the actions to be taken are

not part of a daily routine.

Business Recovery PlansDocuments describing the roles, responsibilities and actions necessary to resume

business processes following a business disruption.

Disaster Recovery PlanningA series of processes that focus only upon the recovery process, principally in responseto physical disasters that are contained within BCM.

Gradual Recovery (Cold Stand-by)This is applicable to organizations that do not need immediate restoration of business

processes an can function for a period of up to 72 hours, or longer, without a re-

establishment of full IT facilities.

Intermediate Recovery (Warm Stand-by)

Typically involves the re-establishment of the critical systems and services within a 24-72 hour period, and is used by organizations that need to recover IT facilities within a

predetermined time to prevent impacts to the business process.

Immediate Recovery (Hot Stand-by)Provides for the immediate restoration of services following any irrecoverable incident.

Stand-by arrangementsArrangements to have available assets which have been identified, as replacementsshould primary assets be unavailable following a business disruption. Typically, these

include accommodation, IT systems and networks, telecommunication and sometimespeople.

VulnerabilityA weakness of the system and its assets, which could be exploited by threats.

- 188 -




- 189 -




Security Management

Introduction

Everyone has heard about the impact a virus can have on a business.

Names as the Kournikova virus, Nimda and the Trojan Horse does ring bells about thevulnerability of our Business and the reliability of the businesses on IT services,

The following example of a different nature occurred recently in The Netherlands.

A national event would take place, which would attract a lot of attention. The eventwas the life chat session with Prince Willem Alexander and his fiancé Maxima on the

Internet. The main telecom provider in the Netherlands provided it and they braggedabout how they could ensure the availability and the high performance of the event.

A group of activists thought this was the time to show the country how vulnerable eventhe big companies are by hacking in to the systems, causing the servers to go downand so interrupting the life chat session for a period of time.

In this case no harm was done but if they had bad intentions they could have easilycaused a lot of damage

- 190 -

http://dubbellink%28%27/asp/mycourse_menu.asp?var=689&een=Security_Management&uitklap=689&language=7&linkeen=689&menugroup=%27,%27inzien.asp?var=689%27)

http://dubbellink%28%27/asp/mycourse_menu.asp?var=689&een=Security_Management&uitklap=689&language=7&linkeen=689&menugroup=%27,%27inzien.asp?var=689%27)




In both cases there is a risk of information being damaged or misused due to a breach

in security or lack thereof.

The security of Information is a key management concern in the modern, electronic

business world. In order for companies to maintain their competitive edge, businessdecisions must be based on accurate, complete and accessible information.

According to BS 7799, Security of information refers to the preservation of:

Confidentiality - Ensuring that information is accessible only to thoseauthorized to have access.

Integrity- Safeguarding the accuracy and completeness of information and

processing methods.

Availability– Ensuring that authorized users have access to information and

associated assets when required.

The degree to which these aspects are preserved must be based on the business

requirements for security. This can be properly understood through accurate risk andimpact analysis. Security management is concerned with addressing activities that are

required to maintain risks at a manageable level.

Objective

- 191 -




The objective of Security Management is twofold:

• To ensure that it complies with the external requirements of, legislation

regarding privacy, insurance policies, and the SLA’s.

• To create a secure environment regardless of the external requirements

Process Description

The process of Security Management is a flexible one and needs to be reviewed continuously to ensure that it

is still up to date. It therefore should, plan, do, check and act in a continuous cycle.

The activities of Security Management are undertaken either by the process itself or by

other processes under the control of Security Management.

- 192 -




Activities

The following activities are part of the security management process:

o Control

o Plan

o Implement

o Evaluate

o Maintenance

o Reporting

Control

In this process the basics for the Security Process are laid out. This includes among others; describing the

roles and responsibilities, description of the sub processes, the Security plan and the implementation thereof

and selecting the tools.

Plan

This sub process will plan the security sections of the SLA’s with Service Level Management. It also includes

addressing the Security sections in the Under Pinning Contracts (UPCs) and the operational level agreements.

- 193 -




Implement

Implementation of all the security measures is the aim of this sub process.

Evaluate

It is necessary to evaluate the implementation of the security measures to see if theyare effective. Regular audits also need to be done to ensure that the process is workingefficiently en effectively.

Maintenance

The maintenance of the security aspects of the SLA’s and the maintenance of the

security plan are the responsibilities of this sub process.

Reporting

Main things that will be reported are:

• Security incidents

• Results of audits

• Performance of security tests

• Identification of incident trends

Roles

In most cases there will be only the Security Manager however in very largeorganization there may be more persons involved in the process.

The security manager is responsible for implementing and maintaining the process.The Security Manager has close ties with the Business Information Security officer

Relationships

The Security Management process has links with all the ITIL processes. Each process

carries out one or more of the activities of Security Management. Although theresponsibilities for these actions are still within the separate processes Security

management provides the input for the activities.

Service Level Management provides information about the required service levelsand receives input about the achieved levels.

Configuration management: The CMDB contains the information about the C.I.’s.

Every C.I. should be classified indicating the required availability, integrity andconfidentiality, which will determine the level of security that is required.

- 194 -




Incident and Problem Management: Incident Management records incidentsregarding a breach of security levels and the cause is investigated and resolved by

Problem Management.

Change Management implements the changes, which ensure security or enhance it.

On the other hand they need to address the security issues for every change. In most

cases the Security Manager will be part of the CAB.

Availability Management is supported by Security Management in the way that the

measures to increase security result in a higher availability of the IT services.

Benefits

Benefits of implementing Security management are:

• Information that is vital to the business is kept secure

• Higher availability of the Information

• Quality of information that goes outside the business is increased.

- 195 -




• Do the services within the SLA’s have the necessary security aspects covered inthe UPC’s and or OLA’s?

• Is there an improvement in the Security levels?• Are the actual Security Levels measured?

• Is the perception of the IT organization improving?

Best practices

http://www.securitymanagement.com/

http://www.ismanet.com/

Also....To Outsource or not to outsource?

The challenge to meet security requirements, to prevent such disastrous impacts, isbecoming more overbearing to organizations. Outsourcing security management could

offer the solutions.

The key questions faced by any organization are:

Should they keep the responsibilities of information security in-house?

Should they develop and train their own IT staff?

Should they develop their own security policies?

Or

Should they contract such services to an outsourcing specialist who is using the latest

available technology, tools and expertise to offer the most efficient service?

The decision to outsource Security Management needs to be weighed carefully as thishighly debatable decision has both pros and cons.

- 197 -









Confidentiality

Ensuring that information is accessible only to those authorized to have access.

Integrity

Safeguarding the accuracy and completeness of information and processing methods.

Availability

Ensuring that authorized users have access to information and associated assets when

required

Privacy

Confidentiality and integrity of information relating to individuals

Verifiability

Being able to verify that the information is used correctly and that the security

measures are effective.

ConclusionIn recent years, IT Service Management has developed into a field in its own right.

Organizations are now so dependent on the automation of large parts of their business

processes that the quality of IT services and the synchronisation of these services withthe needs of the organization are now essential to their survival.

This introduction to IT Service Management aims to provide a thorough introduction tothe field. It not only provides a convenient introduction to the books in the IT

- 198 -




Infrastructure Library (ITIL), but also serves as the first step to prepare for theFoundation Certificate exam in IT Service Management.

It contains a wealth of practical experience collected by the editorial board. It is basedon the latest edition of the ITIL books on Service Support and Service Delivery.

This course aims to provide an effective introduction to the dynamic area of IT ServiceManagement, and will be useful even for those not preparing for the exam. However, it

does not pretend to have the answers to all the questions that arise in a field so

multifaceted as IT Service Management. Instead, it aims to encourage discussions andto compare the best practices with the learner's own experience.

We expect that this course will fulfill a clear need, and it deserves not just to be readand studied, but also to be used wisely in practice.

Gerard Blokdijk, Managing Director The Art of Service

3659122 ITIL Foundations

Documents

Transcript of 3659122 ITIL Foundations