GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Beginners Guide
Foundation Certificate in IT
Service Management with ITIL
Copyright: The Art of Service Pty Ltd 2003.
Version 5.0
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Table of Contents
1
2
3
4
5
6
Foundation Certificate in IT Service Management .........................................................4
1.1 EXIN Exam requirements specifications .................................................................4
1.1.1 The importance of IT Service Management .......................................................4
1.1.2 Service Management processes .......................................................................4
1.1.3 The ITIL management model ..........................................................................5
1.1.4 Basic concepts of ITIL ....................................................................................6
IT Service Management .............................................................................................7
2.1 Introduction to IT Service Management .................................................................7
2.2 ITIL Service Management ....................................................................................8
2.2.1 Business Alignment .......................................................................................9
2.2.2 Processes .....................................................................................................9
2.2.3 Processes, Services and Functions ................................................................. 10
ITIL Overview ........................................................................................................ 12
3.1.1 History of ITIL ............................................................................................ 12
Implementing ITIL Service Management ................................................................... 19
4.1 Introduction ..................................................................................................... 19
4.2 Cultural change ................................................................................................ 19
4.3 Implementation Checklist .................................................................................. 20
4.4 Further reading ................................................................................................ 20
ITIL Service Management Processes ......................................................................... 21
5.1 Service Delivery Set .......................................................................................... 21
5.1.1 Service Level Management ........................................................................... 21
5.1.2 Financial Management for IT Services ............................................................ 22
5.1.3 Availability Management .............................................................................. 24
5.1.4 Capacity Management .................................................................................. 27
5.1.5 IT Service Continuity Management ................................................................ 28
5.2 Service Support Set .......................................................................................... 32
5.2.1 Service Desk .............................................................................................. 32
5.2.2 Incident Management .................................................................................. 35
5.2.3 Problem Management .................................................................................. 36
5.2.4 Change Management ................................................................................... 39
5.2.5 Release Management ................................................................................... 42
5.2.6 Configuration Management ........................................................................... 43
Security Management ............................................................................................. 46
6.1 Introduction ..................................................................................................... 46
6.1.1 Basic concepts ............................................................................................ 46
6.2 Objectives ........................................................................................................ 46
6.2.1 Benefits ..................................................................................................... 47
6.3 Process ............................................................................................................ 47
6.4 Activities.......................................................................................................... 48
6.4.1 Control - Information Security policy and organisation ..................................... 48
6.4.2 Plan ........................................................................................................... 49
6.4.3 Implement ................................................................................................. 49
6.4.4 Evaluate..................................................................................................... 50
6.4.5 Maintenance ............................................................................................... 51
6.4.6 Reporting ................................................................................................... 51
6.4.7 Relationships with other processes ................................................................ 52
6.4.8 Security section of the Service Level Agreement ............................................. 55
6.4.9 The Security section of the Operational Level Agreement ................................. 55
6.5 Process control ................................................................................................. 55
6.5.1 Critical success factors and performance indicators .......................................... 55
6.5.2 Functions and roles ..................................................................................... 56
6.6 Points of Attention and costs .............................................................................. 56
2
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
7
6.6.1 Points of attention ....................................................................................... 56
6.6.2 Costs ......................................................................................................... 57
IT Service Management Tools .................................................................................. 59
7.1.1 Type of tools............................................................................................... 59
7.1.2 The Cost of a Tool ....................................................................................... 59
© The Art of Service Pty Ltd 2003
‘All of the information in this document is subject to copyright. No part of this
document may in any form or by any means (whether electronic or
mechanical or otherwise) be copied, reproduced, stored in a retrieval system,
transmitted or provided to any other person without the prior written
permission of The Art of Service Pty Ltd, who owns the copyright.’
Copyright: The Art of Service Pty Ltd, 2003
3
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
1
Foundation Certificate in IT Service
Management
Let’s begin with the end in mind. A lot of people who first hear of ITIL are surprised to
learn that there are a variety of exams that can be taken. By far the most common is
called the Foundation Certificate in IT Service Management. We’ll cover just what Service
Management is later, but at this Foundation level, it is really the theory of the ITIL
Framework that is being tested.
1.1 EXIN Exam requirements specifications
EXIN are one of the global testing bodies authorised to set and mark questions to test
knowledge in the area of IT Service Management and the ITIL Framework.
The large majority of people who take this Foundations course are interested in also
sitting for the ITIL Foundation Certificate. The section discusses the factors that have to
be considered by those wishing to pass the exam.
1.1.1 The importance of IT Service Management
The candidate understands the importance of IT Service Management in the IT
Infrastructure environment.
The candidate is able to discuss the merits of a process driven approach to information
technology service provision both:
 users and customers of IT Service
 suppliers of IT Services.
1.1.2 Service Management processes
The candidate understands Service Management processes and the inter-relationships
between them.
The candidate is able to:
 Describe the benefits of Service Management processes for an organisation
 Distinguish between ITIL processes and organisational functions and business
processes
 Indicate the elements that contribute towards ITIL process implementation.
Copyright: The Art of Service Pty Ltd, 2003
4
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
1.1.3 The ITIL management model
Using the following diagram as a guide the exam candidate will be able to:
-
Distinguish the objectives, activities and results of the various ITIL processes
-
Provide examples of the data/information flows from one process to every other
process.
Copyright: The Art of Service Pty Ltd, 2003
5
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
1.1.4 Basic concepts of ITIL
The exam participants will also understand the following terms and concepts (note this is not a
comprehensive list, simply an indication):
Application Sizing
Asset Management
Assets
Audit
Availability
Availability Management
Budgeting
Business Process
Call
Capacity Database, CDB
Capacity Management
Capacity Planning
Category
Change
Change Advisory Board
Change Management
Chargeable Unit
Charging
CI Level
Financial Management
for IT Services
First Line Support
Forward Schedule of
Changes, FSC
Full Release
Functional Escalation
Help Desk
Hierarchical Escalation
Impact
Incident
Incident Life Cycle
Incident Management
Integrity
IT Infrastructure
IT Service
IT Service Continuity
Management
IT Service Management
Known Error
Classification
Maintainability
Mean Time Between
Failures
Mean Time To Repair
Confidentiality
Priority
Configuration Baseline
Proactive Problem
Management
Problem
Problem Control
Configuration Item, CI
Configuration
Management
Configuration
Management Database,
CMDB
Costing
Customer
Customer Liaison
Definitive Hardware
Store, DHS
Definitive Software
Library, DSL
Demand Management
Disaster
Downtime
Elapsed Time
Emergency Release
Error Control
Escalation
Failure
Fault
Request for Change, RFC
Resilience
Resource Management
Restoration of Service
Review
Risk
Rollout
Second Line Support
Security
Security Awareness
Security Incidents
Security Level
Security Management
Security Section
Service Catalogue
Service Desk
Service Improvement
Programme
Service Level
Service Level
Agreement, SLA
Service Level
Management
Service Level
Requirements
Service Request
Service Window
Serviceability
Problem Management
Software Item
Procedure
Process
Process Manager
Quality Assurance
Software Release
Status
Strategic
Tactical
Quality Control
Third Line Support
Recoverability
Recovery
Registration
Release Management
Release Policy
Threat
Underpinning Contract
Urgency
Urgent Change
User
Verification
Version
Vulnerability
Work-around
Release Unit
Reliability
Report
Copyright: The Art of Service Pty Ltd, 2003
6
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
2
IT Service Management
2.1 Introduction to IT Service Management
Most organisations now understand the benefits of having Information Technology (IT)
supporting the majority of their business activities. Few realise the potential of truly
aligning the IT department’s objectives with the business objectives. However, more and
more organisations are beginning to recognize IT as being a crucial delivery mechanism
of services to their customers.
When the IT services are so critical, steps must be in place to ensure that the IT group
adds value and delivers consistently.
So the starting point for IT Service Management (ITSM) and the ITIL Framework is not
technology; it is the organisational objectives.
To meet organisational
objectives, the
organisation has
business processes in
place.
Examples of business
processes are sales,
admin and financial (who
have a “sales process”) or
logistics, customer service
and freight who have a
“customer returns
process”.
Each of the units involved
in these business
processes needs IT
Services (eg. CRM
application, e-mail, word
processing, financial
tools).
Each of these services runs on IT infrastructure that has to be properly managed
(Service Management). IT Infrastructure includes hardware, software, procedures,
policies, documentation, etc. This IT Infrastructure has to be managed.
ITIL provides a framework for the management of IT Infrastructure.
Question: Why should we manage our infrastructure properly?
Answer: Proper management of the IT Infrastructure will ensure that the services
required by the business processes are available, so that the organisational objectives
can be met.
Copyright: The Art of Service Pty Ltd, 2003
7
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Historically, these processes delivered products and services to clients in an off-line
environment (the ‘brick-and-mortar’ companies). The IT organisation provides support to
the back-office and admin processes. IT performance is measured internally as the
external clients are only indirectly influenced by the IT performance.
Today, with online service delivery, the IT component of the service delivery can be
much stronger. The way of delivering the service is IT based and therefore internal and
external clients consciously and unconsciously measure the performance of the IT group.
Service delivery is more important than a glimpse of brilliance every now and then. The
internal clients (business processes) and external clients need availability of the IT
services and to be able to expect a consistent performance. Consistency comes through
the ability to repeat what was done well in the past.
IT Service Management is a means to enable the IT group to provide reliable Information
Systems to meet the requirements of the business processes, irrespective of the way
these services are delivered to the external customers. This in turn enables the
organisation to meet its Business Objectives.
Definition:
IT Service Management is the effective and efficient process driven
management regarding the quality of IT services, provided to end-users.
2.2 ITIL Service Management
Any organisation that delivers IT services to their customers with a goal to support the
business processes, needs inherent structure in place. Historically, that structure was
based around functions and technical capabilities. With the ever-increasing speed of
change and the associated need for flexibility a technology driven approach is no longer
appropriate, in most situations.
That is why IT organisations are looking for alternatives. Some alternatives include:
Total Quality Management TQM processes and continuous improvement projects
COBIT as a control & measurement mechanism
CMM for control and structure in software (and system) development
ITIL for operational and tactical management of service delivery
Which single or combination of frameworks selected is entirely dependant on the needs
of the organisation.
For many IT organisations, ITIL is a very good way of managing service delivery and to
perform the IT activities in end-to-end processes.
Further reading on other models and frameworks:
Search on the internet for COBIT. ITIL, CMM, EFQM, Six Sigma, Deming, Balanced
Scorecard, Standards, IT Governance
Copyright: The Art of Service Pty Ltd, 2003
8
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
2.2.1 Business Alignment
By implementing IT Service Management in your IT organisation you support the IT
objectives of delivering services that are required by the business.
You can’t do this without aligning the IT strategy with the business strategy.
You can’t deliver effective IT services without knowing about the demands, needs and
wishes of the customer. IT Service Management supports the IT organisation to align IT
activities and service delivery, with business requirements.
2.2.2 Processes
IT Service Management helps the IT organisation to manage the service delivery by
organising the IT activities into end-to-end processes. These processes have no
functional boundaries within the IT group.
A process is a series of activities carried out to convert an input into an output.
Information flow into and out of each process area will indicate the quality of the
particular process.
We have monitoring points in the processes to measure the quality of the products and
services provided.
Processes can be measured for effectiveness (did the process achieve its goal?) and
efficiency (did the process use the optimum amount of resources to achieve its goal?).
The measurement points are at the input, the activities or the output of the process.
The standards (or ‘norms’) for the output of each process have to be defined such that
the complete set of processes meets the corporate objectives.
If the result of a process meets the defined standard, then the process is effective. If
the activities in the process are also carried out with the minimum required effort and
cost, then the process is efficient.
The aim of process management is to use planning and control to ensure that processes
are effective and efficient.
Copyright: The Art of Service Pty Ltd, 2003
9
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
2.2.3 Processes, Services and Functions
Most businesses are hierarchically organised. They have departments, which are
responsible 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. For example, if there
is an IT service to provide users with access to an accounting program on a central
computer, this will involve several disciplines.
To provide the accountancy program service the computer centre has to make the
program and associated database accessible. The data and telecommunications
department has to make the computer centre 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 the service by
measuring aspects, such as availability, capacity, cost and stability. IT Service
Management to match these quality aspects with the customer’s demands.
ITIL provides a concise and commonsense set of processes to help with the
management, monitoring and delivery of services.
A process is a logically related series of activities for the benefit of a defined objective.
The following diagram illustrates cross functional process flows.
With ITIL we can study each process separately to optimise its quality. The process manager
is responsible for the process results (i.e. is the process effective).
The logical combination of activities results in clear transfer points where the quality of
processes can be monitored.
The management of the organisation can make decisions about the quality of an ITIL process
from data provided by each process. In most cases, the relevant performance indicators
and standards will already be agreed upon. 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.
Copyright: The Art of Service Pty Ltd, 2003
10
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Without clear indicators, it would be difficult for a process owner to determine whether the
process is under control or if improvements are required.
We have discussed processes and we have positioned services. We have highlighted the
difference between functions and processes.
Functionally structured organisations are characterised by:




Somewhat fragmented
Focus on vertical and functional matters
With many control activities
Emphasis on high/low people relationships
In functionally driven organisations we may often see:





Concept of walls or silos; not my responsibility
A hint of arrogance - “We in IT know what’s good for you.”
Steering people instead of steering activities
Because we have to communication
Politically motivated decision making
In contrast once processes are introduced we often see a change towards:






Entire task focus
Horizontal processes focussed towards clients
Control measurements that add value
Interdependence and uniting leadership
Interdependence of independent persons
Accessibility of information
This leads to a culture of:






No boundaries, but interconnections
Customer focused: what is the added value?
Steering activities instead of steering people
Communication because it is useful (fulfilling the needs of the customer)
Decision making is matching & customising
IT service provision is a process
Copyright: The Art of Service Pty Ltd, 2003
11
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
3
ITIL Overview
The IT Infrastructure Library is a set of books with good practice processes on how to
manage IT service delivery. The library consists of many books and CD-ROMs.
The core set of material is the following set of seven tightly coupled areas:







Service Delivery
Service Support
Security Management
The Business Perspective
Applications Management
ICT Infrastructure Management
Planning to implement Service Management
The Service Support, Service Delivery and Security Management manuals are regarded
as the central components of the framework.
These books cover the processes you will need to delivery customer-focused IT services
according to your customers’ needs, demands and wishes.
They help the IT group to be flexible and reliable enough to ensure consistent IT Service
Delivery. The other core books in the library support these central components.
Planning to Implement Service Management
T
h
e
B
u
s
i
n
e
s
s
T
h
The
Business
Perspective
Service
Support
ICT Infrastructure
Mgt.
Security
Management
Service
Delivery
Applications Management
3.1.1 History of ITIL
During the late 1980’s the CCTA (Central Computer and Telecommunication Agency) in
the UK started to work on what is now known as the Information Technology
Infrastructure Library (ITIL).
Large companies and government agencies in Europe adopted the framework very
quickly in the early 1990’s and the ITIL framework has since become known as an
industry best practice, for IT Service Management.
Copyright: The Art of Service Pty Ltd, 2003
12
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
ITIL has become the de-facto standard in delivering IT Services for all types of
organisations. Both government and non-government organisations benefit from the
process driven approach, regardless of the size of the IT department.
ITIL is used globally. ITIL has no geographic boundaries. It is used extensively
throughout Europe, Australia, Canada, USA, United Kingdom and many emerging
countries in Asia.
In 2000 the British Treasury set up the OGC – Office for Government Commerce – to
deal with all commercial activities within the government. All activities formerly under
the control of the CCTA (Central Computer and Telecommunications Agency) were also
taken up by the new department. Even though the CCTA no longer exists, it is noted that
they were the original developers of the ITIL framework.
In 2000, Microsoft used ITIL as the basis to develop their proprietary Microsoft
Operations Framework (MOF).
In 2001, ITIL version 2 was released. In this version the Service Support Book and the
Service Delivery book were redeveloped into much more concise volumes.
ITIL is a pseudo Public Domain framework. ITIL is copyright protected. Copyright is
owned by the OGC. However, any organisation can use the intellectual property to
implement the processes in their own organisation. Training, tools and consultancy
services support this. The framework is independent of any of the vendors.
EXIN and ISEB are the examination bodies that organise and control the entire
certification scheme. They guarantee that the personal certification is fair and honest and
independent from the organisations that delivered the course. Both bodies accredit
training organisations to guarantee a consistent level of quality in course delivery.
At the time of writing the only generally recognised certification is awarded to individuals
There is no independent tool certification or organisational certification.
Copyright: The Art of Service Pty Ltd, 2003
13
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
People and organisations that wish to discuss their experiences with ITIL Service
Management implementation can become a member of the IT Service Management
Forum. The itSMF, just like ISEB and EXIN, aim to stimulate & encourage the best
practice component of ITIL and to support the sharing of ‘war stories’ and to further the
development of the framework.
There is an itSMF chapter in every country that is actively involved with ITIL Service
Management.
Further reading on ITIL:
ITIL website: www.itil.co.uk
OGC website:www.ogc.gov.uk
Buy the ITIL books: www.itsmdirect.com
Examination boards:
EXIN: www.exin-exams.com
ISEB: www.bcs.org.uk/iseb/
ITIL Portal: www.itil-itsm-world.com/
EXTRA READING
The following story is about British Telecom. This is an organisation that faced major
organisational change. As you read the following story, think about the implications on
the delivery of IT Services. At the end of the story, one specific implication is introduced.
Case study: Service Management implementation: British Telecom
The Emergence of BT.
British Telecom (BT) is an international private sector company operating in the field of telecommunications.
From 1912 telecommunications was as part of the Post Office, held in public ownership. It was originally
nationalised to ensure the provision of an integrated telegraphic and telephonic service . British Telecom was
split off from the Post Office in 1981 as a prelude to its own privatisation three years later. The aim was to
make it easier for the management of the two organisations to focus on the business strategies of their
respective operations.
Since 1981 BT has undergone major changes first with privatisation in 1984 and then because of Project
Sovereign in the early 1990’s. What follows concentrates on the build up to and changes associated with
Project Sovereign from the late 1980’s. It is arguable however that this represents some continuation of the
earlier corporate restructuring that surrounded privatisation. The climate for these changes continues to be
shaped by several significant factors including: the development of new technology which has changed the
nature of telecommunications work; the opening up of the market for telecommunications to competition and
the requirement for BT to be able to exploit new international markets for information technology.
BT no longer enjoys the monopoly it once had. At home, competition from Mercury, the cable industry, and an
increasing number of niche telephone operators is taking its toll. For example, it is estimated that 40,000
customers a month are being lost to the cable companies who offer cheaper calls, connections and rentals, as
well as clearer lines and the advantages of new technology. Cable firms claim to have won 470,000 customers
in the three years since they were permitted to offer telephone services. Internationally BT's rivals, such as
AT&T and France Telecom, are battling for the custom of the multinationals that want one supplier to service all
their telecommunication needs.
As well as new competitors such as Mercury and the cable companies who are attacking BT on price, the
regulatory regime is also becoming harsher. OFTEL have recently stated that prices on BT's basic services must
now be kept to 7.5% below the rate of inflation. Although many of the same pressures affect BT's rivals, BT
argues that it suffers most because it maintains a network that runs the length and breadth of the UK.
Copyright: The Art of Service Pty Ltd, 2003
14
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Symptoms
Project Sovereign and change of culture in BT.
BT have launched several initiatives to transform the company however the most significant was the Project
Sovereign which involved both adopting total quality management values and encouraging employees to focus
on customers needs. In March 1990, the Chairman of BT announced fundamental changes to the organisational
structure of BT. These emerged from the findings of the Scoop Project undertaken by a team of BT Senior
Managers into how the company should tackle the telecommunications business of the 1990’s. This suggested
that BT’s existing structure would prevent the company from achieving its full potential. Based largely on
geography rather than customers or markets, it lacked the flexibility and integration necessary to meet
changing market conditions.
The plan for change was called Project Sovereign because according to the Chairman it was:
“The single most important thing that we are ever likely to do because it puts the customer at the top of our
organisation".
Over the following 12 months the old structure of BT based on geographical districts and product divisions gave
way to 3 customer facing divisions: Business Communications Division to serve the needs of business
customers; Personal Communications Division to meet the requirements of the individual customer; and a
Special Business Division to manage a range of facilities such as Yellow Pages and Cellnet.
These new ‘customer facing’ Divisions were to be supported by a division with responsibility for the coordination of BT’s portfolio of products and services; a World-wide Networks Division to plan, build, operate and
maintain the switching and transmission network in the UK and globally; a Development and Procurement
Division to provide a broad spectrum of technical services including research, development and design,
fabrication, testing, problem-solving, planning and consultancy. In addition, this division was given
responsibility for developing and managing a group wide supplier strategy and procurement service. Finally
functions such as strategy, finance, personnel running across the business were to be handled by Group HQ.
Figure 1 summarises the organisation structure introduced under Project Sovereign.
Customers/Markets
Business
Communications.
Personal
Communications
Special
Businesses.
Products and Services Management
World Wide Networks.
Development and Procurement.
Group HQ (Strategy, Finance, Personnel, etc.)
Figure 1. Organisational structure on 1 April 1991.
In a briefing session on the changes given by BT Directors to top BT managers the factors which shaped the
new structure and its essential features emerged. The new BT required radical change and a more flexible
approach to organisation and management. The Group Finance Director explained that:
“BT is seeking a fundamental change in its approach to the markets it serves - it is a massive change and not
tinkering at the edges. Moreover, it is ultimately linked to a change in our cost base - a leaner organisation and
flatter management structure. The most successful telecommunications company in the world has to be flexible
around a low cost-base.”
In a presentation entitled “Management and Culture” BT’s UK Managing Director argued that surveys in the
company showed that many employees wanted radical change and the opportunity to contribute more to the
company. Managerial leadership he suggested would need to release these pent-up energies. The key will be
providing the managerial leadership that will release and make use of these pent-up energies. However, he
noted a substantial reduction in the numbers of managers will be inevitable in order to “flatten” the company’s
multi-layered pyramidal organisation and quicken response between management and workforce. Project
Sovereign has reduced the total number of layers of management in BT from twelve to six.
One of the first changes to take effect with Sovereign was the integration of the UK and international marketing
and sales organisation under a unified management structure. This was intended as a very visible indicator of
the customer orientation of Project Sovereign. This was stressed by the Sales and Marketing Director:
“This change allows our people to direct their energies towards meeting customer needs and nowhere is this
more true than with the marketing and sales community that we will be bringing together into one structure.
Copyright: The Art of Service Pty Ltd, 2003
15
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
This group of people will be at the forefront of the organisational change, demonstrating our determination
and commitment to put the customer first.”
In summary, Project Sovereign was to lead to:
· A flexible market-driven structure for business and personal customers, with the necessary technical and
commercial functions to meet their needs.
· A single interface for all BT’s customers backed up by systems and specialised support.
· An increased sales revenue through protection of BT’s largest business customers, capturing the substantial
opportunities available in the smaller business market and from the information-intensive personal customer.
· An integrated approach for business customers, to meet their rapidly expanding
international needs.
· Consistency for both business and personal customers, with the target to deliver uniform excellence across
the customer base.
· Integrated product management, removing duplication, eliminating gaps and managing potential conflicts to
the benefit of customers and the company.
Cultural change and the impact on employment in BT.
BT, in common with many other telecommunications companies, has been faced with having to make the
transition from a vast state-owned, public-service, bureaucracy to a flexible and responsive, private sector,
high-technology company. The challenge of transforming an organisation that was rumoured to have more
vehicles than the Red Army is huge. Not only do work practices have to be changed, but the culture also has to
be shifted so that the staff are focused on providing services demanded by customers.
In practice, this “cultural shift” has involved a huge reduction in staff numbers. Many employees who did not
like the new ethos, or found it difficult to adapt, simply left in one or other of the company's generous
redundancy programmes.
As a consequence of the increased competitive pressures outlined above costs have had to be reduced and the
company has to move faster and become more flexible. BT, like many other companies are finding that speed is
now a crucial competitive weapon and that several layers of management can slow down the decision making
process.
Another source of pressure on management jobs stems directly from the job losses lower down the hierarchy.
Technology has had an important role here, as the company no longer needs as many operators, and
consequently, it no longer needs as many managers to supervise them. Similarly, as junior staff have left, the
company has found itself with too many managers at higher levels. BT currently employs 32,000 managers to
organise its workforce of 153,000. The ratio of managers to staff has fallen to one to five although BT plans to
lower that to one manager to ten workers.
When the company was privatised in 1984 it employed 244,000 people and reached a peak of 245,700
employees in 1990. In 1994 it employed 185,000 people. Between 1992 and 1994 almost 28,000 engineers
and telephone operators, more than 5,000 middle managers and 876 senior managers accepted voluntary
redundancy.
The Voluntary redundancy schemes, Release 92 and 93, proved to be run away successes.
For example, BT indicated that it wanted to shed 20,500 jobs under Release 92. John Steele, BT's personnel
director, later commented in a newspaper article:
“We were told we would never get rid of 20,000 jobs in a year “We were told it's impossible, it's never been
done before”. In fact, as many as 45,000 applied to go with 85 per cent of the formal complaints, registered
after the redundancy programme, coming from those who were not selected to leave.”
Release 92 in particular proved to be almost too successful. Incentive payments to leave before the end of July,
worth 25 per cent of salary, caused 19,500 staff to leave on the same day almost causing the company's
administration to collapse under the weight of work and causing severe disruption to customer services. More
than 16,000 people were rejected for severance and courses to maintain morale were instituted in those areas,
mainly the operator service and telephone customer contact jobs, that were particularly oversubscribed.
Redundancy payments range from 40 weeks' pay for 10 years of service to a maximum of 72 weeks' pay for 14
years. Staff who were with the company before 1971 get three years' pay.
An engineer with long service could qualify for a payment of £60,000 while a manager on £35,000 could
receive more than £100,000. Most schemes involved a combination of lump sum and early pension entitlement.
The average package of benefits for those leaving cost BT is about £38,000, although a small number of senior
managers are believed to have received more than £200,000.
The scheme cost an estimated £1.15bn. Although BT has not revealed a final price of the scheme it did explain
that even with more than 40 per cent more people being accepted for severance the total bill did not rise in
proportion as ‘the unit cost was lower than BT expected’ .
Copyright: The Art of Service Pty Ltd, 2003
16
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Publicly BT has always said that it tried to make the package of benefits attractive to all ages.
However, in 1993, unions representing workers at BT claimed that the company had introduced a grading
system that could be used to target older staff. The system was based upon an individual's annual performance
assessment, their attendance records and whether or not disciplinary action has been taken against them. The
proposal that age should form part of the points system was dropped by BT after complaints from the National
Communications Union and the Society of Telecom Executives. At that time 15,300 people under 45 had taken
severance, of the older workers, 4,000 were aged 45-50 and 10,000 were 50-60. The company's standard
retirement age is 60. In January 1994 the chairman, Sir Iain Vallance was able to state :
“It is now almost exactly 10 years since BT was privatised, the natural turnover of staff means that many
staff have never worked in the public sector. We now have the younger more responsive workforce that this
industry needs.”
In 1992 and 1993 the majority of the cuts were voluntary and had fallen on lower and middle management,
operators, clerical staff and engineers. However in March 1994 BT announced that 6,900 senior managers out
of BT's 32,000 management-grade employees will be targeted for ‘significant compulsory reductions’ as not
enough were volunteering to leave under its job reduction programme. It also announced that it was
considering compulsory redundancies for its most senior managers as part of a drive to lose 35 of its 170
managers at director level.
All managers at this level earn over £50,000 a year with the average wage being £76,000 a year.
Although the logic of de-layering and downsizing may be clear, it seems that managers that are more senior
are reluctant to go and, until recently, BT has been loath to sack them. The reluctance to accept voluntary
redundancy may be because senior managers have more agreeable, and better-paid jobs or it may be because
they are more worried about finding another job elsewhere - although figures from the International Labour
Office show that only 3% of professionals and only 5% of managers in the UK are unemployed in comparison
to 13% of plant and machine operators and 13% of craft workers.
The Customer Service System (CSS).
In the late 1970's, BT (then part of the GPO) had six mainframe sites and very little local computing. When BT
split from the Post Office in the early 80's BT began to set up local computing centres. Each area had set up its
own databases and soon similar information was being held in two or even three different places. The cost of
attempting to keep all of this information consistent and up to date was spiralling out of control.
The decision was taken to centralise all of the information at a district level and telephone areas began to be
amalgamated into districts. This process marked the beginnings of CSS. Essentially CSS was conceived as a
“Customer Service System”, i.e. the aim was to provide a single source for all of the information relating to a
single customer. An operator could access all relevant information for that customer by telephone number,
address or name and could call up the customer's details on to a screen almost instantaneously.
After privatisation BT looked at several systems from a number of vendors and began setting up CSS's in 1985.
People from the districts were seconded to the headquarters and a National User Group (NUG) formed to aid
the setting up of the various CSS's.
At a national level Setting up CSS involved creating 29 databases for the 29 separate districts that existed at
that time with each database containing information about 12 specific areas such as customer records, line
records, billing information, etc. Each CSS needed to hold the details of over 1 million customers and service
around 2000 terminals. The installation of CSS into the various districts was spread over several years.
The CSS system was initially created as a system to support operations within individual districts and although
CSS was almost universally acknowledged as a great help in providing customer support many felt that the
management information aspect of the system appeared to have been added almost as an afterthought. While
CSS was an efficient in certain respects, such as tracking installations or repair work, it did not really provide
the information needed by managers or, if it did, it was in a form that was of little use to them.
The announcement of Project Sovereign in 1990 and the move to three new ‘customer facing’ divisions:
-
Personal Customers (PC),
Business Customers (BC)
Special Businesses (SB)
provided a new impetus to the development of CSS although this was not without problems.
Previously every CSS had been set up on the basis that all customers were treated in more or less the same
way. There was no distinction made between, for example, business customers or personal customers. The
amount of time and effort that had gone into setting up the existing CSS, and the technical problems of
splitting the 29 existing databases into three – one for BC, one for PC and one for SB - meant that another way
Copyright: The Art of Service Pty Ltd, 2003
17
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
had to be found to make the existing Information Systems work within the new company structure. The
solution was to keep the same databases but give more access to people who required it. Thus the decision to
create three new divisions meant that in order for CSS to continue to function managers, even at relatively
junior levels, had to have the ability to ‘have visibility of other work areas’.
Previously there had been a bureaucratic system of passwords and access codes that limited access to the
various areas of a CSS. However, once the principle of greater visibility was established improvements in
technology opened other areas for organisational change. It now became possible to switch automatically
information between districts so that a person based in one district could update or amend records held in
another district. Similarly it also became possible to monitor work loads and allocate resources across the
functional and geographic divisions in BT.
Although all of this was now technically possible, some organisational problems remained as, in the past BT had
relied on local expertise and each region had done things in a slightly different way. CSS provided an
infrastructure that was relatively tightly controlled in terms of what it allowed a manager to do. However, in
order to bring about some of the proposed new changes it would, in some senses, need to be even more tightly
controlled as every region would now have to operate in the same way.
The need to ensure consistency between regions lead to some dissatisfaction with the speed with which the
system could be changed or modified. In the past when the system needed to be changed or updated this could
often be accommodated at a local level, now however, each change or update needed to be worked out and
agreed across the whole of the national network.
Copyright: The Art of Service Pty Ltd, 2003
18
Version 5.0
4
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Implementing ITIL Service
Management
4.1 Introduction
ITIL Service Management is something that impacts the entire IT organisation.
Implementation of end-to-end processes can have a big impact on the way things are
done and can initiate a lot of uncertainty and resistance with staff.
For these reasons, it is important to implement ITIL Service Management with a step-bystep and steady approach.
The following model is an example of such an approach.
Developing ITIL processes is a fairly easy job to do! Making sure everybody understands
the processes and uses them is more difficult and requires serious planning.
It is advisable to use a project management approach to ITIL Service Management
implementation and stay focused on the clearly defined end results (many different
Project Management methodologies exist. The Trademark owners of ITIL (the OGC)
publish PRINCE2 (Projects in Controlled Environments)).
4.2 Cultural change
A small part percentage of the implementation project will be about process design. Most
of the challenge lies in cultural change and personal motivation of staff to use the endto-end processes as the better way to do business.
Any change leads to feelings of vulnerability and loss of control. These feelings generally
manifest themselves through feelings of resistance. The most important thing in this
stage of the ITIL implementation is to keep the focus on the reason why your
organisation needs ITIL Service Management in the first place.
19
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
4.3 Implementation Checklist
DO:










Perform a feasibility study first
Use what is already good in the organisation
Take it slowly
Stay focused
Appoint a strong project manager with end-to-end focus to drive this
implementation program
Be brave enough to ask for help when you need it
Keep in mind that you are dealing with personal issues
Keep communicating WHY your organisation needs this
Measure your successes continuously
Enjoy the milestones and share them with the IT group
DON’T:
 Try to mature all the processes at the same time
 Start with a tool
 Start without management commitment and/or budget
 Force ITIL upon people
 ‘ITILISE’ your organisation, keep thinking…
 Rush, take your time to do it well
 Go on without a reason
 Blindly follow the herd
 Ignore the positive activities already in place
4.4 Further reading
Planning to Implement Service Management – an OGC publication.
Copyright: The Art of Service Pty Ltd, 2003
20
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5
ITIL Service Management Processes
5.1 Service Delivery Set
The following chapters describe in brief the Service Delivery processes. These processes
are generally referred to as “tactical” processes.
5.1.1 Service Level Management
This process provides the contact point between the IT organisation and the customer.
Within the ITIL books, ‘the customer’ is defined as being the person who pays for the
services. It should therefore be someone with decision-making authority, e.g. business
manager.
Service Level Management is the process that ensures that the IT organisation knows
what services they can deliver and organises for the IT group and the customer to agree
on the levels of service that need to be delivered.
It also ensures that the IT group can consistently deliver these services to the customer
by ongoing monitoring the service achievements and reporting these to the customer.
Extra reading
To report or not to report
A lot of the organisations that start implementing Service Level Management fall into the
trap of over-reporting. Everything is monitored, and all results are reported back to the
client.
Negotiate the reporting strategy with your customer during the SLA-negotiations. A
report is only valuable if your clients use it for their own work.
Another pitfall is the fact that some people only report when things are going wrong. The
image you build with an agreement like that is a negative one. The client only hears from
IT when there is a problem or when service levels aren’t met. ALWAYS report on the
positive things as well!
It’s OK to say NO…
Often, when you start implementing Service Level Management in your organisation
you’ll find that you can’t deliver a lot of the user’s requests. You can’t deliver because
you don’t have the underpinning processes in place, you don’t have enough budget and
other required resources.
Service Level Management is all about managing the expectations of your clients.
Internal and external agreements
The beauty of implementing ITIL is that everybody in the organisation speaks the same
language, and therefore you need to be very strict with your choice of words. A Service
Level Agreement is an internal agreement with your clients. An agreement with an
external party is called an underpinning contract. An agreement within the IT group
itself is called an OLA (Operational Level Agreement).
Copyright: The Art of Service Pty Ltd, 2003
21
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.1.2 Financial Management for IT Services
When Service Level Management agrees with the customer on Service Levels, it has to
be able know how much money is involved in delivering this service. Especially when the
cost for IT services is to be charged on to the customer.
Financial Management for IT Services allows the IT organisation to clearly articulate the
costs of delivering IT Services.
There are 3 fundamental components with this process.



Budgets
IT Accounting
Charging
Note: Charging is an optional activity and is dependant on the charging policy of the
organisation as a whole.
Financial Management needs input from all other processes regarding the costs that form
part of the service delivery. It will also deliver input to the other processes, e.g. financial
information for the cost-benefits analysis within Problem Management and Change
Management.
EXTRA READING
Q. Why is business financial management important to the IT professional?
Isn't that the CFO's responsibility?
Competent financial management is critical to the success and very survival of a wide
variety of organizations. In the technology community, it is common to select the chief
financial officer or the chief information officer for advancement to the CEO position.
For the CIO professional looking for a promotion or a greater understanding of the IT
arena, an understanding of the basics of financial management has become invaluable.
The goal of business financial management is to maximize value. Successful financial
management requires a balance of a number of factors, and there are no simple rules
or solution algorithms that will ensure financial success under all circumstances. The
overall goal toward which corporate financial and IT managers should strive, is the
maximization of earnings per share, subject to considerations of business and financial
risk, timing of earnings, and dividend policy.
The basic concepts of the fundamental principles of accounting, analytical techniques
for interpretation of financial data, basic budgeting concepts, financial planning and
control and the analysis of long-term investment opportunities are applicable to IT as
well as finance. Financial and IT professionals who can profitably harness the principles
and techniques of financial and information resources will be able to manage their
organizations more effectively than their competitors.
Copyright: The Art of Service Pty Ltd, 2003
22
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Exchanging wooden dollars?
Many organisations decide not to do a physical charge out to their internal clients because
it would only add up to the administrative procedures within the organisation.
Financial management in this type of organisations is used to gain insight into the cost
involved in the delivery of IT services and to raise the awareness with the clients. Instead
of invoicing the client, a monthly report is sent out to update the client on their ITexpenditure.
Copyright: The Art of Service Pty Ltd, 2003
23
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.1.3 Availability Management
Contrary to popular belief, Availability management deals with ensuring that the services
are available according to agreed levels.
It does not set out to guarantee the maximum level of availability, nor is it about
reporting on server availability as a stand-alone issue.
This process ultimately links all IT components together and manages the links and
weaknesses between the IT components to ensure the availability of the service delivery
to the customer.
Availability works closely together with Capacity Management. This is a logical connection
as you can’t ensure the availability of the service when the capacity is insufficient. There
is also a close link to Problem Management as the availability expert is often technically
skilled and able to analyse root cause analysis.
EXTRA READING
Distributed Availability (IBMs approach (technical document))
Introduction
Distributed availability is the ability to ensure predictable, reliable user access to key
applications and computing resources. Maintaining distributed availability in
client/server environments is a complex and expensive proposition, yet it plays a
critical role in maximizing your investment in client/server computing.
Businesses that have embraced and deployed client/server computing face major
challenges such as keeping mission-critical applications up and running. This document
addresses why this is difficult, compares different approaches to solving this challenge
and describes why Tivoli's automated solution to distributed availability is uniquely
suited for enterprise client/server management.
Distributed Availability
Client/server computing puts mission-critical computing resources such as systems,
databases and applications in the hands of those who need them most, end users.
However, without the proper management tools, it is difficult to maximize the
availability of these crucial resources.
Providing distributed availability gives information technology (IT) staff an efficient,
automated way to ensure the high availability of key computing resources. It allows IT
staff to meet its service-level commitments. It ensures that company personnel who
depend on uninterrupted access to mission-critical business applications are more
productive. It allows organizations or individual business units to minimize lost revenue
opportunities that can occur when mission-critical applications and computing resources
are not up and running efficiently.
Why It's Difficult
Leading global corporations have embraced distributed client/server computing as their
vehicle for implementing mission-critical applications. However, distributed
environments and applications are much more complex and dynamic than their
mainframe predecessors.
It is easier to track the performance level of computing resources in a centralized data
centre environment because there are only a few large systems--typically from one
vendor and located in one place. In contrast, the distributed client/server environment
has a large number of dispersed, heterogeneous systems that grow and change at a
Copyright: The Art of Service Pty Ltd, 2003
24
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
rapid rate. For example, IT staff are often unaware that individual workgroups have
installed their own systems or reconfigured their environments.
With many remote sites, different types of systems from multiple vendors and a
constantly changing environment, the challenge is to provide application and computer
resource availability without requiring system administration experts at each remote
site.
Providing distributed availability includes the following activities:
 Automatic configuration and deployment of policy-based resource monitors and
actions
 Automatic problem detection through distributed monitoring
 Automatic preventive and corrective actions
Traditional Solutions
The major problem with most of today's monitoring tools is that they are not scalable-they simply do not work in a large, distributed client/server environment.
While a mature set of mainframe performance tools exist, these tools only work well for
monitoring a centralized computing shop. They are simply not designed to handle
enterprise-wide monitoring.
With the advent of LAN computing, a second type of monitoring tool has emerged. LANbased monitoring tools typically focus on presenting many, often hundreds, of alerts
per system. These tools work within one LAN segment and assume that a server or
workgroup administrator exists for each LAN. This scenario is suitable for small
computing environments but does not work for an enterprise with hundreds of LANs at
many remote locations.
Typical problems with LAN-based monitoring tools include:
 Many tools focus solely on alerting
 Filtering capabilities are often absent, causing alert-information overload
 IT staff must handle each alert manually
 Tools must be configured individually on each monitored machine at the remote site
 Many tools can not initiate automatic corrective actions
 Most tools are not extensible, restricting the addition of monitors or corrective
actions
 Many tools are SNMP-based. These tools work well monitoring network devices but
are dependent on a central collection point, are not secure and not scalable.
Further, they generate polling and network traffic.
 Most existing monitoring tools have severe limitations in distributed client/server
computing environments, especially in the areas of scalability and efficient central
configuration. The limitations of existing monitoring tools make it difficult to monitor
a large, dynamic computing environment.
The Right Approach for Client/Server
Tools that work for mainframe or for individual LAN environments do not provide a
scalable solution for large, distributed computing environments. To meet the unique
requirements of client/server computing, the solution must:
 Configure and deploy monitoring agents from a central site
 Be easy to configure so that deployment does not become labour-intensive
 Provide alarm filtering at the source
 Avoid generating an excessive amount of network traffic
 Provide a method of automatically correcting repetitive problems at the source
 Alert staff only for serious exception conditions
 Allow you to build policy for monitoring a group of similar systems or applications
 Allow you to build policy for corrective actions on a group of similar systems or
applications
 Be easily extensible, allowing you to add customised or third-party monitors
Copyright: The Art of Service Pty Ltd, 2003
25
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0

Provide an easy method to launch third-party debug or performance tools on an
exception condition
Conclusion
Providing distributed availability in the client/server environment can be a complex and
expensive proposition; yet it plays a pivotal role in the maximisation of an
organisation's investment in client/server computing. Without the proper management
tools, it is difficult to maximise the availability of these distributed resources.
Copyright: The Art of Service Pty Ltd, 2003
26
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.1.4 Capacity Management
The essence of Capacity Management is to ensure that the right amount of capacity is at
the right location, for the right customer, at the right time and at the right price.
Capacity Management aims to optimise the amount of capacity needed to deliver a
consistent level of service to the customer. Balancing or spreading workload is a key
method to avoid wasting money on excess capacity that is unnecessary.
Capacity Management has a very close relationship to Availability Management,
Configuration Management and Service Level Management.
EXTRA READING
Why a Capacity Plan?
With cheap hardware prices, capacity planning may be seen to have lost its importance.
You can always upgrade later!
The fact that hardware systems can be upgraded easily has, in recent times, diverted
attention away from this key process area.
There are two main concerns that make capacity planning critical.
The first is the rate of technical change in the distributing computing sector. We now
measure progress in "Internet years" -- equivalent to about 90 days of a calendar year.
The second is that today’s systems are primarily being developed within complex 3-tier
architectures.
This rapid change, coupled with the increase in complexity 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 added
before 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 an
integral part of the overall operation. Upgrade downtime is increasingly expensive in
both time and resources. In addition, the added complexity of the environment typically
requires more care, due to the interdependency between various application
components.
Capacity planning is driven purely by financial considerations. Proper capacity planning
can significantly reduce the overall cost of ownership of a system. Although formal
capacity planning takes time, internal and external staff resources, software and
hardware tools, the potential losses incurred without capacity planning are staggering.
Lost productivity of end users in critical business functions, overpaying for network
equipment or services and the costs of upgrading systems already in production more
than justify the cost of capacity planning.
Copyright: The Art of Service Pty Ltd, 2003
27
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.1.5 IT Service Continuity Management
IT Service Continuity Management prepares for the worst case scenario.
ITSCM investigates, develops and implements recovery options when an interruption to
service reaches a pre-defined point.
The ultimate choice of which option to choose, is made by the customer as part of the
SLA agreements. Price has an obvious factor in selected the appropriate recovery option.
In the current global situation, a structured approach to IT Service Continuity
Management has become more and more important. Business processes rely more and
more on IT Services and IT components are more under ‘attack’.
Defining the pre-conditions that constitute a disaster is part of the ITSCM process. Such
definitions form an integral part of any Service Level Agreement relating to the provision
of services.
EXTRA READING
Availability Solutions: What Do You Need? (source: www.contingencyplanning.com)
Run New Search by: Bill Merchantz
Pages: 22-25; September, 2002
There are many options available to you when selecting a managed availability solution. The following review of
products, services, and technologies will help you choose the best one for your needs.
The previous articles in this series have provided the foundation for choosing a managed availability solution.
As they explained, the search for availability solutions begins with a thorough understanding of the nature of
the problem. How much does an hour of downtime cost? Are your needs application-centric or data-centric?
What is the absolute and relative importance of recovery time objectives (RTO) and recovery point objectives
(RPO) in your business? The answers to these and other questions determine the appropriate size of your
managed availability investment and where you should direct it.
Once the objectives and scope of your solution are defined, a wide range of services, foundation technologies,
and products are available with which to build it. In fact, some of the foundation technologies, such as
journaling, may already be available in your database management or operating systems but have been
deemed, until now, unnecessary or inappropriate for implementation in your systems. When developing a
managed availability solution, all options and approaches should be carefully considered in order to build the
optimum solution.
Services
Assessment — The first step in managing availability is to assess the current environment and seek availability
options. Using an outside vendor to provide this service adds an objective viewpoint and a wealth of preexisting
knowledge, skills, and experience.
Planning — In addition to a high-level plan that describes the overall direction and desired end goal, a program
also needs separate plans for each step along the way.
Education, Training, and Documentation — Human error is a major contributor to unplanned downtime.
Education, training, and documentation on the use and maintenance of each system and its components can
help reduce this type of problem.
Copyright: The Art of Service Pty Ltd, 2003
28
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Auditing — Business requirements constantly evolve in ways that directly impact internal systems. Add staff
turnover into the equation and the result is a volatile environment that can create unexpected availability
exposures. A partial- or full-system failure will certainly highlight these new vulnerabilities, but a less-costly
approach is ongoing vigilance through regular audits of the managed availability plan and its implementation.
Foundation Technologies
Backup and Restore — The most basic level of data protection is to back up data so that it can be easily
restored. Backups are generally performed on a regular schedule, such as nightly.
Journaling — Database journaling allows a destroyed database to be recovered up to the last committed
transaction. Journaling eliminates the problem of “orphan data” — data added or updated since the last backup
preceding a destruction event. Of course, like backup data sets, journals must be stored separately (preferably
remotely) from the production database to ensure that both are not destroyed in the same disaster.
Commitment Control — The commitment-control function of most commercial database-management software
protects the integrity of transactions in general by rolling back to their previous state any specific transactions
that were not completed at the point of an outage. The complete series of updates can then be reentered upon
system recovery.
Products
Uninterruptible Power Supplies — Power outages are the most common cause of abrupt system failures.
Therefore, uninterruptible power supplies (UPSs) go a long way toward reducing downtime frequency. When
configured properly, they can also reduce the duration of downtime. When a primary power outage occurs, the
UPS can maintain system operation long enough to save main storage, thus protecting data and simplifying
system startup when the power returns.
Fault-Tolerant Hardware — Some hardware includes internal redundancy, along with the means to monitor
each component’s operating status and seamlessly switch to a backup component when necessary. Inoperable
components can typically be replaced without stopping the system.
RAID (Redundant Arrays of Independent Disks) — RAID spreads enough information across multiple disks to
allow the disk subsystem controller to recalculate any missing information in case of a disk failure. It does not,
however, protect against the failure of other disk-related hardware, such as a controller, an I/O processor, or a
bus.
Disk Mirroring — When properly configured, disk mirroring can eliminate single points of failure. Often used in
combination with RAID5, this approach requires that data be concurrently written to each unit in a set of
identical disks, incurring minimal CPU overhead or increase in system complexity. However, mirroring all data
requires at least twice as many disks.
Alternate Communication Paths — Core business functions often depend on a variety of systems and sites. For
example, a company may take orders at one facility and fulfill them at a remote warehouse, with order data
transmitted between the two over communication lines. If the line is disrupted, orders will have to be sent to
the warehouse manually or, worse, not transmitted at all. The only way to combat these exposures is to
maintain alternate communication paths.
Redundant Systems — A multiple-systems approach that continuously maintains real-time replica systems
offers the highest possible level of availability. It duplicates applications, user data, and system data on two or
more systems that may be geographically dispersed. In addition, it can quickly switch users from the primary
Copyright: The Art of Service Pty Ltd, 2003
29
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
system to a backup system when necessary. Thus, unlike backups and disk mirroring, this approach can
eliminate all types of user-processing interruptions.
Redundant systems can be coupled with third-party software assuming full responsibility for system
resiliency. Or, they can be tightly coupled in a cluster, with the operating system assuming primary
responsibility for monitoring and managing the cluster.
Although a backup system can be located in the same building or on the same site as the primary system, it is
highly recommended that the backup system be located in a geographically distant location so that an event or
disaster affecting a wide area, such as a storm, flood, or earthquake, will not affect both systems.
Because such disasters are rare, most companies justify the investment in redundant systems based not on
disaster recovery but on their ability to provide continuous operations. In a single system environment,
database saves and reorganizations may shut down applications or, at best, severely impair their performance.
Worse, hardware and software upgrades can shut down applications for hours or even days. These problems
are avoided in a redundant-system environment. Users are simply switched to the backup system whenever the
primary system requires maintenance. Furthermore, database saves and read-only access tasks, such as query
and reporting jobs, can be done on the backup system, thus eliminating their burden on the production
environment.
When considering a replication solution as part of a full managed availability solution, include these questions in
your evaluation worksheet:

Does the solution allow for seamless, real-time replication of data to a backup system?

Does the solution also replicate system objects? If not, it may not be possible to recreate the application and
user environment on the backup system. If, for example, a user profile is changed on the primary system,
that change should be reflected on the backup.

Is the replication technology application-independent? If not, costly and error-prone application modifications
will be required.

Does the solution provide system monitoring to automatically detect failures?

If the solution provides monitoring, can it automatically initiate a failover to the backup system in case of an
outage on the primary system, without the need for any user or operator intervention?

Does the solution offer a way to quickly and easily switch to a backup system, with minimal user interruption,
when maintenance is required on the primary system?

Does the solution enable activities normally associated with planned downtime, such as software and
hardware upgrades or database reconfigurations, to be conducted in the background while applications stay
in production and users stay online?
Blended Products/Services
Third-Party Recovery Sites — The purchase and maintenance of a complete set of duplicate hardware and
software and the off-site facility to house them is cost-prohibitive for many companies. Third-party recovery
sites, which share costs among a number of customers, provide an affordable alternative.
Copyright: The Art of Service Pty Ltd, 2003
30
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Data Vaulting — Journaling does not fully protect orphan data, since a disaster that destroys a system would
likely also destroy the journal files in the system. Data vaulting eliminates this vulnerability by capturing
changes made to production databases and immediately transmitting them over a network to a recovery site. If
no problems occur during the day, the vaulted data can be discarded when a new backup tape arrives at the
recovery site. Should a disaster occur at the primary site, the vaulted data can be applied to the recovery site’s
database after the most recent backup tape has been loaded. The result is a database that is current up to the
point of failure.
Solutions that Fit
Because of the diversity of data topologies, hardware, software, and application platforms, few elements in the
managed availability toolkit can be delivered as a shrink-wrapped offering. A purely off-the-shelf product would
have to be so generic as to be far from optimal in any installation. Therefore, companies should look for a total
solution that includes methodologies, software, processes, training, support, and services that allow them to
effectively tailor and adapt the solution to their unique environments.
Foundation Questions
Clearly, business needs and technology architecture determine the optimal managed availability solution.
However, planners should ask some general questions about each of the options they evaluate:

Is the solution a comprehensive, end-to-end offering built upon a proven methodology, incorporating the
software, services, support, documentation, and overall expertise necessary to provide full managed
availability?

Does the solution manage all operation-critical elements of application availability (e.g., data, objects,
security, work management, and user connectivity) and server requirements (e.g., environment configuration
and power)?

Is the solution proven and supported by the company’s platform manufacturer(s) and/or application
developer(s)?

Does the solution support new and emerging technologies?

Is the solution capable of handling the full-transaction volumes and complexity of the company’s systems? Is
it scalable and flexible enough to keep pace with growth?

How long has the solution been in the market? What is its market share?

Has the solution been rigorously proven in a number of real-life installations? Can reference sites be visited?
Addressing these questions can help planners ensure that they select the solutions that best fulfill their
organizations’ requirements. The next article in this series will take the process one step further by providing
some suggestions on evaluating solution providers.
About the Author
Bill Merchantz is the founder, president, and CEO of Lakeview Technology, a provider of managed availability
software solutions. He has many years of hands-on experience as a customer/manager of IT solutions.
Copyright: The Art of Service Pty Ltd, 2003
31
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.2 Service Support Set
The following chapters describe in brief the Service Support processes. These processes
are generally referred to as “operational” processes.
5.2.1 Service Desk
The business users / end-users need IT services to improve the efficiency of their own
business processes. When they can’t use the IT services, they have trouble achieving
their objectives.
End-users of services need a single point of contact with the IT organisation.
The Service Desk should be the single point of contact for all end-users. This is where
ALL questions, issues and requests are logged and recorded.
The type of Service Desk you need depends on the requirements of your customer base.
ITIL defines Service desk types in terms of skill and structure.
Skill levels:




Call Centre
Unskilled Service Desk
Skilled Service Desk
Expert Service Desk
Service Desk structures:
 Centralised Service Desk
 Distributed Service Desk
 Virtual Service Desk
 Split Function Service Desk
EXTRA READING
Extract from a Public Discussion forum regarding Service Desk costs.
Question: How do you calculate the cost of a call?
JJ - 3/26/01 3:26:00 AM
How do you calculate your cost of call or cost of a service request? What types of
costs do you include in the total and how often are the costs measured?
Answers:
PM - 3/28/01 7:25:00 AM
Several years ago, I purchased a white paper from Help Desk Institute, which
reviewed different calculations for cost per call. While the paper is somewhat
outdated, it does give you an idea of some basics. Our cost per call includes: salaries,
benefits, utilities, rent, insurance, phones, training, office supplies, etc. Basically we
include any cost related to the support centre. We complete the calculation quarterly.
JF - 3/29/01 2:46:00 PM
Evidently the META and Gartner Groups have done studies to show that password
reset calls cost somewhere between 25-35 dollars per call that lasts an average of
11.5-14.5 minutes. Furthermore, depending on security policies, an employee has an
Copyright: The Art of Service Pty Ltd, 2003
32
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
average of 3-4 reset requests per year. So, the average cost in that area is fairly
easily definable.
AN - 4/1/01 9:45:00 AM
Suggest you take a look at the "Interactive Help Desk tool" recently posted in the HDI
Superstore. The tool calculates the cost per call for given Service Levels very quickly
and accurately.
RF - 4/2/01 11:36:00 AM
In addition to the departmental costs that can apply to all departments, a few other
factors must be taken into consideration. These include length of call, quality of
assistance received, whether the issue was adequately resolved, and whether or not
the user must call back for additional assistance. For example, if the user must call
back and has to rehash the situation, costs escalate and are difficult to control. If,
however, the support technician is continually and adequately trained, even if he
must stay on the phone for some time to resolve the call, this will result in a lower
number of calls, a higher number of satisfied users, and an overall lower help desk
budget.
DM - 4/4/01 3:29:00 PM
We use a simple calculation that works well for us. We take the entire dollar value of
my annual budget and divide it by the number of customer contacts we have. This
includes all inbound e-mails, voice mails and phone calls. In addition, we add in the
number of outbound phone calls we make to get a problem resolved. Using just the
inbound calls, we average $13-$16/call. If we add in the outbound calls (a very large
number - representing a significant amount of time and therefore money) we are
under $9.00/customer contact. This calculation method may not be "according to the
book," but we have used it for years and as I said earlier, it works for us.
DS - 4/10/01 12:35:00 PM
One thing most help desk organizations do NOT do in calculating cost per call is,
include the support cost beyond the help desk (i.e. second and third level support
whether captive or outsourced). This leads to misleading and even detrimental
management information.
In the extreme, the lowest cost per call would be seen in the help desk that
dispatched out the most of their service incidents the quickest, thus saving greatly on
their own labour and phone costs while driving total costs up as the inefficiencies from
buck-passing creep in. Any cost per unit measurement that focuses only on a portion
of the whole is worthless without the full picture.
JC - 4/11/01 4:59:00 PM
One individual mentions the cost for handling a password reset and one suggestion
for handling such calls would be to give your users the option to do the reset
themselves via an IVR, which is what we do. It thus lowers the cost per such call to
less than a dollar versus it being done thru the help desk, that cost is in the 7.50
range. Our IVR is our first level of support for the client with the Response Centre
being the 2nd level and so on. Our cost per call is calculated based on the total
monthly expense for running the Response Centre, which includes salaries, fringe,
supplies, etc. This versus the total number of calls handled gives us a cost per call
that we can manage to.
BC - 4/11/01 5:17:00 PM
Combining several statements already posted, the budget of ALL support levels that
are involved in Incident Resolution (Level 1, 2 etc.) divided by the number of
Incidents may deliver a cost per call. A further breakdown may be used in which Level
1 calls are calculated using their average resolution time, Level 2 calls are calculated
Copyright: The Art of Service Pty Ltd, 2003
33
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
using their resolution time, etc. This would lead to a more accurate calculation of cost
per call, depending on level of resolution. However, outbound calls are not included in
this case either.
GF - 6/5/01 9:48:00 AM
In a previous note Justin Farmer sites some statistics from Gartner and Meta reports
that I found very interesting.
Source: www.thinkhdi.com
Copyright: The Art of Service Pty Ltd, 2003
34
Version 5.0
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
5.2.2 Incident Management
This process is in place to get the end-user back to work – following an interruption to
normal service delivery - as soon as possible. It is symptom-driven and the only concern
is speed of response, and the continuation of the business process.
Incident Management uses information out of the Problem Management process (work
arounds and Known Errors) and the Configuration Management process (linking Incidents
to Configuration Items)
A large component of Incident Management is the administration and tracking of the
incident itself.
EXTRA READING
The line between the function of the Service Desk and the Incident Management process
is perhaps the area of greatest confusion for most people regarding ITIL.
It is best explained by making the point again that the Service Desk is a function and
that Incident Management typically lies inside that function.
If an end user calls the Service Desk they are making contact with a functional part of
the IT Service Delivery. What takes place after the call is made and the end user is being
looked after is part of the Incident Management process.
Generally, most organisations have their Service Desk staff conducting Level 1 incident
management support. However, this is not a caveat and the decision is dependant on the
selected skill level of staff and Service Desk structure selected.
Level 2 and beyond Incident Management staff can be tightly integrated into the Service
Desk area, or they may be recognisable as a separate group of staff.
In a lot of organisations who have adopted ITIL, the concept of Level 3 support has given
way to the Problem Management process.
35
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.2.3 Problem Management
It is the intent of Problem Management to find Known Errors in the IT Infrastructure.
Everything you do within this process is focused on:
o
o
o
o
Finding what the Known Error is (Problem Control  diagnosis)
Identifying alternative solutions for the removal of the Known Error (Error
control)
Raising a request for change (RFC) to request for the deletion to happen
Checks after a change is performed to see that the Known Error is gone
The Problem Management process also has an element of proactive troubleshooting. The
concept here is to identify and facilitate the removal of errors before they manifest
themselves as end-user complaints or queries.
EXTRA READING
Getting to the Root Problem
Event correlation and root-cause analysis tools promise a lot, but real-world results are mixed, say
users.
Automated network management software - sophisticated stuff that promises an unprecedented ability to
monitor a corporate network - is on the horizon.
But skeptical IT managers say the tools still aren't smart enough. They want
artificial intelligence that can diagnose a network problem and get it right at
least seven out of 10 times.
Such automation relies on event correlation and root-cause analysis tools.
The concept behind the tools is simple: keep track of network devices and
relationships, automatically fix minor problems and refer more complex
snafus to the network manager.
But skeptical IT managers are demanding proof of better automation,
bedrock interoperability and broader usefulness before they will buy such
tools.
"We've looked at these tools," says Tom Revak, domain architect at
pharmaceutical company GlaxoSmithKline PLC in Research Triangle Park,
N.C. But "until the artificial intelligence exists that can automatically update
a dynamically changing network, it's just one more pretty little map of what
could be."
Historically, users have been "skeptical that software can meaningfully
achieve what human expertise has achieved," says Dennis Drogseth, an
analyst at IT consultancy Enterprise Management Associates Inc. in Boulder,
Colo. Drogseth researched and wrote the consultancy's report on root-cause
analysis and event correlation that was released in December.
Who’s Using It
Of 135 companies surveyed by
Enterprise Management
Associates, 60% are doing
event correlation.
Those 81 companies use it to:
Speed problem resolution 33%
Improve service delivery27%
Reduce staff, overhead 24%
They’re spending:
More than $200,00027%
$100,000 to $200,00016%
$10,000 to $100,00044%
They consider acceptable a rate
of:
75% to 90% accuracy43%
More than 90% accuracy40%
But how satisfied are they?
Very48%
Somewhat
Exactly, says Kristina Victoreen, senior network engineer at the University of
Pennsylvania in Philadelphia. "We tried building on the autodiscovery that
source: Enterprise Management
Spectrum does, but we spent more time fixing what it had discovered,"
Associates Inc., Boulder, Colo.
Victoreen says. "The guys who do [the model building] found it was quicker
to build the topological model of the network by hand, which is very timeconsuming." Spectrum is a management tool from Aprisma Management Technologies in Durham, N.H.
The tools "need to sense when something out of the norm occurs, such as a critical deadline that forces people
to work around the clock, and normally noncritical failures become critical and require immediate response,"
says Revak. "If they can't do this automatically, the administrative overhead greatly outweighs the return on
investment."
The moment of truth for users seems to come when the software tools "can successfully automate problem
diagnostics 70% of the time or better," Drogseth says in the report. At that point, "users believe they are
justified in the investment.
"That 70% mark is being met today by most of the better products," Drogseth says.
The benefits can be substantial, he says: smoother-running networks, better service-level delivery, reduced
staff requirements and lower overhead. These benefits, together with advancements in the software and a
Copyright: The Art of Service Pty Ltd, 2003
36
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
reduction in the costs of deployment, are driving an increase in the use of root-cause analysis and eventcorrelation tools, Drogseth says in the report.
"There's no way we could manage without it," says Chris Vecchiolla, IT
project manager at Royal Caribbean Cruises Ltd. in Miami. Each of Royal
Caribbean's 18 ocean liners has an IT staff of two people, but most systems
management is handled remotely from Miami via satellite.
Royal Caribbean uses Compaq Insight Manager and Unicenter from Islandia,
N.Y.-based Computer Associates International Inc. to manage and monitor
"about 170 items, such as SCSI card failure and out-of-threshold notices on
servers," Vecchiolla says.
Escalating alarms notify both onboard and Miami-based IT staffers of
problems. When the system detects a virus, it automatically destroys it and
notifies onboard IT staff of the action via a banner on a monitor, Vecchiolla
says. But should a server exceed a predetermined threshold, Miami staff
could be paged to handle the problem, he says.
Because Royal Caribbean's ships cruise around the globe through every time
zone, remote management from Miami sometimes occurs while onboard
staffers are off-duty. When the Miami staff works on a ship's systems,
"Unicenter automatically picks it up and generates a banner that goes to the
onboard systems manager that tells them the date, time, workstation
accessed, what was done," Vecchiolla says. "The [onboard IT staffers] like
that a lot."
Drogseth says that more than half of the enterprise-level companies with
which he spoke are beginning with automation's "lowest common
denominator, alarm deduplication."
If a server goes down, each attempt by any user or device to access it can
generate a separate alarm, which doesn't describe the root cause of the
problem. Deduplication lets a network manager see a single, server-down
alarm instead.
A Kansas City, Mo.-based unit of Boston-based financial services company
State Street Corp. isn't doing root-cause analysis, but it does use Spectrum
for alarm deduplication, says David Lembke, State Street's network services
manager.
The University of Pennsylvania has been using Spectrum for five years to
reduce the number of alarms reported by a single event, Victoreen says. "It
works reasonably well, assuming we've built the model correctly," she says.
But "it turns out [that] a big map with red dots flashing to show alarms is
not that useful for us."
Drogseth says that in his interviews with 40 midsize to large companies,
most IT managers said they know they must start automating, because
networks have grown too large and complex to manage without automation
tools.
Though Revak is skeptical, "that's not to say we're not interested," he says.
"We're rethinking trying to model all of our networks and maybe moving to
trap aggregators or event correlation engines," Victoreen says.
IT managers are looking beyond the network focus that most vendors have
stressed and are seeing extended uses for the tools, such as to support
performance, help desk functions, inventory and asset management, change
management, and security. Not all tools support all such extensions,
Drogseth says.
Users have viewed automation
for root-cause analysis and
event correlation as "more work
than it's worth, requiring too
much labor and knowledge for
rules to be appropriately
defined for a specific
environment," says Drogseth.
Glossary:
Advanced correlative
intelligence: A problemisolation method cloaked in
secrecy by most root-cause
analysis tool vendors. This is
where language is most
likely to become obscure or
insubstantial.
Event correlation: Examines
the relationship among
events across an IT
infrastructure to narrow the
search for the cause of a
problem.
Object data store:
Knowledge specific to
devices, applications and
connections that provides a
database of codified detail
for understanding objects
and their relationships. An
extensive object data store
can contain object
performance data for use in
modeling routine
interactions across device
types such as servers and
routers.
Polling and
instrumentation: Provide
ongoing event data about
infrastructure availability,
performance and topology.
They can include common
availability metrics, as well
as CPU utilization or even
remote monitoring.
Presentation and context:
Encompass issues around
what you see, how it looks
and what it tells you. No
matter how detailed the
reporting, unless it’s
presented in a way that
suggests a solution, it’s just
so much noise.
Vendors of most of the tools also claim some kind of predictive capabilities.
A network that learns over time can not only help prevent problems, but it
can also increase job satisfaction by releasing IT staffers from grunt work
and calling on them only for more difficult questions.
But where most such artificial intelligence efforts fall short is in detecting
subtle changes, Revak says. "Through repeated small changes, the norm
[can] shift very near the failure point, setting up a significant failure
situation for the next small deviation from the newly established norm," he
says.
Predictive capabilities vary greatly, and not all are based on sophisticated artificial intelligence techniques,
Drogseth says.
Copyright: The Art of Service Pty Ltd, 2003
37
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
At the bottom of the range is basic linear trending. An algorithm can
determine how long it will take a server to reach capacity if usage
increases by, say, 20% per month.
At the other end are sophisticated tools like CA's neural network-based
Neugents, Drogseth says.
A Neugent can look at historical data about network resource usage and a
company's business cycle, says a CA spokeswoman. By aggregating and
correlating data on network infrastructure and business relationships, the
Neugent might predict that a server would reach capacity in six weeks but
drop back to 30% in the seventh week, she says.
Royal Caribbean plans to implement CA's Neugent for Windows NT
networks, which "will take us to another level of management," Vecchiolla
says.
Root cause analysis: Isolates
the cause of failure or poor
performance.
Topology: The map of where
things are. It can detail both
the physical (Layer 2) and
logical (Layer 3) network, and
move on up the Open Systems
Interconnection stack to
include configuration
information relevant to systems
and applications.
Before the root-cause analysis industry achieves that new level of management, however, it must hurdle the
stumbling block of standards, Drogseth says.
Part of why the University of Pennsylvania isn't "getting as much back as we'd hoped for is that we have a lot of
different software from different vendors, and they have a lot of different proprietary schemes and interfaces,"
Victoreen says.
"The systems management industry must develop the standards and interoperability capabilities required for
the tools in the event, problem, change, configuration, inventory, workload management, capacity [planning],
performance [monitoring] and security areas to work together," Revak says. "Each of these disciplines contains
some part of the overall equation."
Root-cause analysis and event-correlation tools aren't layered onto a network so much as they are woven into
its fabric, Drogseth says.
De facto standards such as Java, HTML and XML help provide a cooperative interface between different vendors'
products.
But true interoperability demands a common thread, "a standard structure of data maintained in the object
store" - a database of network devices, applications and relationships, Drogseth says.
"At its most esoteric, standards refers to that platonically perfect state that never gets achieved," he says.
"What we're seeing is some adoption of some standards by some vendors."
Users should look for vendor partnerships to ease root cause tool deployment and management, he says.
That's easier now than several years ago, when one New York-based financial services firm began doing rootcause analysis. "We had to build a lot of things ourselves because they weren't available at the time," says the
firm's IT vice president, Gary Butler.
"We're using the [System Management ARTS Inc.] correlation engine, and we're feeding it with data from
Tibco's smart agents" and San Francisco-based Micromuse Inc.'s NetCool presentation software, says Butler.
"We can't always find the root cause 100% of the time, but we can at least find the more serious event, and
that keeps us from wasting time with all the symptoms."
Revak says, "As the industry matures, the best bet is for companies to focus on developing their event
infrastructure technology - a prerequisite for any advanced management - their people and their processes.
Technology is not the most important. [Vendors] dislike it when I say this, but most important are the people
and the processes" and the relationship between them.
Source: Computerworld
Copyright: The Art of Service Pty Ltd, 2003
38
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.2.4 Change Management
A robust Change Management process ensures that the Change Manager is in full control
of the changes to the IT infrastructure.
Change Management is NOT about performing changes risk free. It is about performing
changes with a minimal risk OR consciously taken risk.
It is therefore important to involve the clients or client representatives in the change
management process.
All projects start through Change Management as all projects wish to change something
to the IT Infrastructure: they either modify the current infrastructure or add/remove a
component.
Change Management is more than just Change Control. The Change Management
process starts with the RFC being raised and keeps control from the assessment and
acceptance of the RFC through to the Post Implementation Review.
All other processes issue RFC’s to Change Management for necessary upgrades to
improve their effectiveness and efficiency. Change Management needs information from
all other processes in order to perform the risk assessment regarding requested changes.
EXTRA READING
Five Intranet Management Problems You Can Solve With a Change Management System
(Source: www.earthweb.com)
Remarks made around the office:
"I updated that document yesterday, but it's not appearing on the Intranet. What happened?"
"The new version's wrong! Did we back up the old one?"
"Chris and I were editing the same file at the same time, but I finished first. His changes overwrote mine!
"Who made that change?"
"Only the Webmaster is allowed to change any files, so your changes might be implemented by Christmas."
If you hear statements like these on a regular basis, you may be suffering from change out of control. Changes
in files are necessary and beneficial, but they also have to be controlled. People in a development environment
know all about this problem, and have devised a sound way of managing the volume of changes to software
files. The discipline of managing, controlling, and automating changes in your files is called software change
management.
The Five Problems
You only need to go as far as your Webmaster to learn all about the volume of change in a Web or Intranet
environment. Just like their developer cousins, Webmasters struggle to manage the magnitude of change to a
Web site. Now, with new integrated authoring and browsing tools like those available from Netscape
Communications, making changes to a Web site is as easy as saving a file and pressing a "one-button publish."
This technology opens the Web up to a whole new breed of content providers making changes to a site. Before
the technology, changes had to go through the Webmaster because of the difficulty in executing the changes.
Now, these new tools have empowered everyone to make their own changes. And consequently, new change
problems have emerged. The following are some examples of common change problems affecting Intranet
sites.
1. Your update didn't appear. Even though you've made a change to a document, the old version remains on
the Web. Until the new version appears, the time you spent updating it is wasted. If you can't find the new
version, you will have to redo the work. This problem typically happens because two copies of the same file
exist and the file you updated is not the file copied to the Web site. Say, you make a private copy "just in
case." A commendable precaution but prone to problems. This private copy will often by-pass scripts and
automated update tools. You may not notice that two long pathnames differ in a single component and you
alter the wrong file. With two copies of a file, mistakes will happen. Or to put it another way, duplicate files
diverge.
Copyright: The Art of Service Pty Ltd, 2003
39
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
You can solve this problem by controlling both how you change the original source document and how you
make those changes available on your Intranet site. Some kind of approval or promotion mechanism is most
useful. One of the first rules of change management states that you store each source file in only one place.
2. You can't restore an old version. You need to examine an old version, but you can't. The backup has failed,
or the changes were made during the time period between backups, or no backup exists for that directory.
You usually discover this problem when you realize someone has made a mistake in the new version or
released information before its time. For example, suppose you plan to change your internal purchasing system
and, with it, the related forms on the Web site. If the new forms are incompatible with the old forms, then new
page on the Web won't work with the old system. If you haven't put the new system in place yet, chaos will
follow. Prevention is the best solution to this problem. One clear method of prevention requires having a
backup methodology and an archive of all versions of the files on the Web server. Then, when a mistake does
occur, the older version can quickly replace the mistaken version. This ideal archiving system is simple,
automatic (or nearly so) and easy-to-use.
3. Multiple authors, multiple overwrites. Two people opening the same file at the same time for editing creates
an opportunity for file overwrites. In this situation, one person may save a file every minute while the other
makes changes over a couple of hours before saving. Consequently, that file is a free-fire zone. As soon as the
second person saves the file, all of the first person's changes disappear. Neither is careless, but a single save
command has erased two hours of work.
A change management system saves changes sequentially. It allows anyone to read a file at any time but
controls the ability to save changes to that file. If you want to change the file, you must lock it first. This lock
warns others that the file is being changed and prevents them from making changes. Then, when you finish
changing the file, you unlock it making it available for someone else to lock, edit, and unlock.
4. You don't know who changed what or when you discover a mistake in a document; you have no way of
knowing who changed the file. With most systems you have difficulty determining who changed a file and
when. Even if a file system records that last changed a file and at what time, that's usually all the information
the system provides. This kind of system rarely keeps a history of all the changes or of the reasons for those
changes.
Since a proper change management system keeps a record of all the changes, it's easy to add who changed the
files and when to the record. Ideally, you will enter a reason for the change like, "Fred added a new section to
the white paper on change management." On an Intranet site, every object should have its own history. A
single page may contain many different objects (graphical images, audio files, applets, etc.) each with its own
history. For example, if your corporate logo changes, regular visitors to your home page will recognize the
change. However, the change will actually take place in the image file not to the home page itself. A record of
changes to the home page won't help track changes to the logo.
5. Your Webmaster does all the work Organizations solve the problem of managing change to a Web site by
assigning the responsibility for change to their Webmaster. If an organization funnels all the work through a
single person, the Webmaster, then it automatically assumes that he or she is accountable for the accuracy of
the content. That funnel soon turns into a bottleneck, and the Webmaster who must do everything soon finds
he or she has no time to do anything.
A change management system approaches change in a more reasonable way. It evens out responsibility for
change by enabling multiple, authorized people to make changes to Web content. Much of the work involved in
putting files on a Web site is quite simple. It involves changing content, copying files, and confirming the links
are correct. These kinds of changes users can make for themselves rather than requiring the Webmaster do it
except for the possibility of mistakes.
By protecting the files on your Web site against unwanted changes, a sound change management policy
empowers users to make changes to documents in a structured, managed way. People can then work without
the fear of losing data and the Webmaster can have a moment or two of peace of mind.
Advanced features
As already mentioned, some users find the basic features of version control are not enough for their needs.
Typically, these people deal with the files rather than their content. They include team leaders, project
managers and Web site managers. The problems faced by these more sophisticated users include:
Finding differences: A user often needs to visualize the differences between any two versions of a file.
Object re-use: Some components of the Web pages on a site are standard for the site (i.e., graphics and logos)
and should be re-used as much as possible. Other parts are solutions to common problems and the program
should re-use these as well. Can the software handle groups of files? Synchronizing groups of files: Files
change at different rates; a team or project leader must ensure that particular sets of file revisions are kept
together.
Security: Large development projects require enhanced security. Some project maintenance actions should be
restricted to qualified or approved users.
Copyright: The Art of Service Pty Ltd, 2003
40
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Approving content: If the Intranet is used as a staging ground for documents that will later appear on the
external Web site, there must be some way of distinguishing approved files and documents from those not
approved, provisionally approved or under review.
Team management: A Webmaster or a team leader cares about all the changes made to a group of files and all
the files locked for editing at any one time. This person requires a "group-view" of the file system that differs
from the narrowly focused view of a single user.
A Policy for Change
Begin with a sound policy when applying a change management system to Web development. Policy is the
rationale behind tools and procedures, and without a sound one, the tools won't be nearly as helpful as they
could be.
When drawing up a policy, consider both the organizational structure and the logical structure of the Web site
or sites:

Are people organized into teams, departments or, perhaps, in a flat structure? How does that reflect the
Web site?

Are files under a version control of any sort?

Is there both an Intranet and Internet site? If so, how do the content standards differ?
Once you determine the site's structure and needs, consider the process by which documents get to the site the approval cycle. Different organizations have different procedures. The common history of a published piece
of dynamic content is:

New content is generated. This may mean modifying old content or creating new content.

Content is approved. The person who created the content may be the only approving body, or there may
be a formal review process.

The Web page is tested. Again, the person who created it may handle this strictly, or there may be an
official tester or testing body.

The new content is made public.
The order may occur in a slightly different sequence, but these four steps happen. Some may even happen
more than once. If the content is not approved, new content must be generated again.
You must also ask specific questions when formulating a policy that identifies responsibility at different stages
in the process of documents getting to the site.
1. Who approves documents or file content?
In order to streamline the use of new content on a Web site, there needs to be an approval process in place.
The approval process will depend upon the nature of the content. For example, an art director may have
approval over the use of images or logos, especially if they apply across the entire organization, and a
development team leader may have to approve a new Java application.
2. Who will test the changed pages to ensure they are correct? How will the test be done?
This is an important part of the approval and validation process. Web pages on the Internet represent an
organization and mistakes do not reflect well even if they're relatively minor ones such as spelling errors or
incorrect links.
3. Who has access? In other words, who can replace or write to the files?
Even on an internal site it may be useful to establish a process for approval and access. On the external site,
perhaps only the Webmaster may change files, or perhaps the Webmaster and team leaders. In most
organizations, the person who places the file on the external server essentially approves it for publication.
Conclusion
The World Wide Web is almost synonymous with change. Essentially, every time you save a document you
create a new version of a Web document or applet -- you make change. Mastering the Web depends upon
managing that change properly. The ability to manage change depends, in turn, upon an effective version
control system. Version control reduces lost information, eliminates confusion and duplication of effort creating
bottlenecks, and keeps productivity up.
The growth of the Intranet has brought in a new breed of content providers: people not interested in learning
the technical details of version control. Therefore, version control must be made convenient, easy and invisible
to them. The key lies in integrating version control tightly with the Web server.
Of course basic version control isn't enough for Webmasters or professional developers who develop
complicated applications for the Web or organize large Web sites. These people require advanced version
control to deal with internal and external servers, firewalls, multiple source files and approval cycles. Advanced
version control is built upon a sound policy and understanding of the site's needs. It requires additional features
such as extensive audit trails, access control, and organizational tools such as projects and sandbox directories.
With a sound policy and the right tools, both the new breed of content providers and the old suppliers can
manage change effortlessly and with integrity.
Copyright: The Art of Service Pty Ltd, 2003
41
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.2.5 Release Management
As soon as Change Management has approved a change, where appropriate, it hands it
over to Release management to release the change into the appropriate environment.
Release Management performs version control and controls the movement of software,
hardware and other infrastructure components from the development environment to the
test environment and into production.
Release management also manages the Definitive Software Library (DSL), in which it
stores all master copies of the software CIs. The Definitive Hardware Store (DHS) is a
physical storage area with the authorised spare parts and other components of the nonsoftware CIs.
All products that go into the DSL of DHS need to be checked for damage and viruses
before they are stored.
The management of impending release notifications is an important part of this process
(especially with regard to advance warnings to the Service Desk).
EXTRA READING
Example of a release notice to end-users:
KDE 2.2 Release Plan
The following is the outline for our KDE 2.2 release schedule.
The 2.2 release, unlike the 2.1.1 release, will come with new functionality and improvements in many areas of
KDE.
We aim for the following improvements among others:
Better printing framework
IMAP support in kmail
All dates given here are subject to revision, but we will try our best to stick to them.
A.Guy is acting as release coordinator for the 2.2 releases.
KOffice 1.1 will be released independent from KDE 2.2. The KOffice 1.1 release schedule can be found here.
KDE 2.2 final
Monday July 16
The HEAD branch goes into deep-freeze. All commits should be posted for review _BEFORE_ commiting.
Sunday July 29
Last day for translations, documentation, icons and critical bugfixes commits.
Monday July 30
The HEAD branch of CVS is tagged KDE_2_2_RELEASE and the day is spent testing the release a final time.
Tuesday July 31
The tarballs are made and released to the packagers.
The rest of the week is spent testing the tarballs, packaging and writing the announcement and changelog.
Friday August 3
The source and binary packages are uploaded to ftp.kde.org to give some time for the mirrors to get them.
Monday August 6
Announce KDE 2.2.
Frequently Asked Questions
Which packages are included?
The current list of packages that will be in the 2.2 release is:
kdegraphics
kdeadmin
kdemultimedia
kdegames
kdeutils
kdetoys
kdepim
kdesdk
kdebindings
kdevelop
kdoc
New package: kdeaddons
New package: kdeartwork
Copyright: The Art of Service Pty Ltd, 2003
42
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
5.2.6 Configuration Management
There is no easy way to manage your IT service Delivery in a consistent manner, when
you don’t know all the resources that you have at your disposal.
Lot’s of IT organisations don’t know what they own, or what they use to deliver the IT
services to their customers.
Configuration Management is the process that keeps a track of all the Configuration
Items you need in order to deliver the IT Services.
Information about Configuration Items (CIs) is held in a Configuration Management Data
Base (CMDB).
CIs include –and are not limited to- Hardware items, software items, SLAs, Disaster
Recovery Plans, policy statements, etc.
Crucially a CMDB also defines relationships between CI’s. That is, whether a CI “is part
of”, “is connected to”, “belongs to”, “joins with”, etc. another CI.
Configuration Management makes sure that the information about the CIs, stored in the
CMDB, is accurate and up to date. All other processes rely heavily on this process.
EXTRA READING
Building a CM Database:
Nine Years at Boeing
Susan Grosjean
Boeing Electronic Products
A Boeing organization developed an Oracle-based database to track problems during the life cycle of the Boeing
777 airplane. Over nine years, it has evolved from mainframe to web implementation as technology has
become available. This article reviews some basic approaches to developing configuration management
databases and includes resulting lessons learned.
The Need for a Database System
Boeing Electronic Products (EP) designs and develops some of the avionics 1 for Boeing Commercial Airplanes
(BCAG).
About 1990, when the 777-airplane program was getting started 2, EP was instructed to develop an
electronic database to track and record problems encountered during design and development of EP electronics.
BCAG wanted a database it could access. After the 777 was fielded, all airplanes were to use this database.
The existing problem reporting system was paper-based. One paper copy of each problem report (PR) was
stamped "original." Multiple copies were made for each person assigned to work the problem. Each person
would record his or her response by writing on the hard copy. Periodically, the Integrated Product Team (IPT)
leader, responsible for a given piece of avionics, would call together all members of the team, known as the
Engineering Review Board. These meetings could last for hours, trying to take all inputs and create one original
PR. An easier way was needed to consolidate board members' input.
Requirements Definition and Implementation
Engineers, IPT leaders, and other potential customers did not seem to know what they wanted/needed in a
problem reporting system. All the organizational requirements were surveyed (EP Configuration Management
Plan, RTCA/DO-178B "Software Considerations in Airborne Systems and Equipment Certification," EP Software
Quality Assurance procedures, etc.). Using the PR as a guide, the existing process was captured in a flowchart
representation with a text description of each block. A requirements document was developed from this process
document.
The numbering scheme for the PRs was used in conjunction with automation of the problem reporting
process. A two-field scheme was used. The first field was an Avionics Product (LRU)3 designation such as 7WEU
(777 Airplane Warning Electronics Unit). The IPT leaders and auditors needed a list of all PRs for a desired
component. A search on this first field would provide that list. The second field was a four-digit number that
was assigned sequentially. Once a PR receives this two-field dash number, it cannot be deleted, so there is no
break in the numbering sequence. This simplified the IPT leader's control and made any audit process easier.
Four text fields, as well as signature blocks, were associated with each PR. Each text field needed to
Copyright: The Art of Service Pty Ltd, 2003
43
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
accommodate extensive data (20,000 characters each). In the PR heading were smaller fields for pertinent data
needed for tracking and reporting. The entry of valid data to these fields was enforced through the use of pulldown lists that provided all valid options for a given field.
Because of the size and quantity of PRs, the speed and capacity of a mainframe was needed. EP chose to
use Oracle on a VAX mainframe rather than an IBM due to the availability of VAX programmers in EP. EP was
unable to find an existing user interface to meet its requirements. User access to the mainframe was via dumb
monochrome monitors or by loading an access icon to the personal computers
A major implementation complication was the need to have five variations of the PR (i.e. variations on the
fields and associated process). The struggle to agree on a uniform PR form and process was futile; each user
organization wanted its own little corner of the world. The result was five different PR databases. Maintaining
requirements, processes, procedures, updates, and training for five different databases was a nightmare.
Throughout the PR process (see Figure 1), e-mail messages were to be triggered to inform personnel and to
assign tasks. There are now 43 possible messages for each PR. For instance, after an originator of a PR has
completed the appropriate "title" and "description" fields, the system sends the PR as an e-mail message to
those responsible for the product (component) in question. The length of these e-mail messages was a
challenge, since they included the 20,000-character-length text fields. This will be solved by e-mailing only a
brief message that includes a URL access to the web site that the assigned can access to see the complete PR
and perform the applicable function.
The system also automatically changes the status of the PR as it moves through the phases shown in Figure
1. Portions of a PR are approved in each phase. After approval, the status changes and fields are locked,
preventing changes by unauthorized persons. Engineers, configuration management specialists, and IPT leaders
have different levels of authorization.
User Acceptance of the System
After implementation of the requirements and extensive testing, the database was given to the users. A
program directive and a users manual were written. Hands-on training was also conducted—not an intensive
course, but intended to acquaint the user with the database and convey some of the rationale used for its
creation.
Function Keys
The users' first reaction was, "This database is not user friendly." No one liked using the function keys to move
around the database. Many keyboards did not support the function keys we were using, and corresponding
control keys, ^B or F10 = Exit had to be developed. These keystrokes were displayed at the bottom of each
screen.
Unlike the paper PR, the electronic version forced the entry of required information. The IPT leaders did not
like the fact that the database forced everyone to do business the same way, and that it had checks and
balances in place to ensure this practice.
But users liked the information the system provided: the position of a given PR in the life cycle, e-mail
notification of PR status, who was assigned to work PR related tasks, and visibility into process bottlenecks. If a
PR had languished on someone's desk for months, the IPT leader needed to know that. Sometimes the IPT
leader was surprised to find that the languishing occurred on his or her own desk. Canned reports included
listings of all PRs by responsible IPT leader or by assignee, and totals of the quantity of PRs by open and closed
status.
Windows
Three years ago, Oracle offered Developer/2000, allowing a user-friendlier front end. We needed to retain the
VAX, as by now all four-text fields had increased to 65,000 characters each. With high-level management
backing during the implementation of the front end, all Seattle-based groups adopted a single PR form. The
groups also agreed with using basically the same process.
The Parts Engineering Organization in Seattle levied additional requirements, as it wanted a way to track
and record problem reports involving obsolete parts.
Since single part obsolescence is often common to several LRUs, a process enhancement was created to
generate multiple corresponding PRs. A parent PR (the first PR written) is created and duplicate copies are
made for each impacted LRU. These child copies retain a link to the parent. When the child PRs are closed, the
parent PR can be closed.
Requirements expanded beyond Seattle to Irving, Texas—our manufacturing site. Irving has a problemreporting system also implemented in Oracle. A requirement to transmit engineering problems between the
Seattle and Irving databases was accomplished by developing an interface that transfers the PR from their
database to Seattle's.
The Seattle system now has approximately 1,000 users with about 40,000-recorded problems. The
database tracks and creates reports for any type of problem encountered by EP (product, test, obsolete parts,
production) as well as lessons learned, action items, corrective actions, and PRs against the database itself.
Intranet
Access via the Boeing web is partially implemented. This provides access from more locations but with slower
response times than those experienced by users who access the system directly using the software application
windows front end. The database is migrated off the VAX to a Unix operating system.
Copyright: The Art of Service Pty Ltd, 2003
44
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Lessons Learned
You might consider commercial off-the-shelf tools that may meet most of your requirements or investigate
other organizations or divisions using a tool similar to your requirements. Implementing this system has been a
lot of work spread sporadically over nine years. Remember, EP had in-house Oracle developers; many
organizations do not have similar resources.
Establish a team to consider new requirements. One result of nine years of experience is EP's use of an
Engineering Review Board that helps determine if a change or enhancement will benefit all users. This database
has a PR type, which enables the users to write a PR against the PR system. These PRs include problems
encountered and enhancements.
Designate a focal point to write and transmit requirements to the database programmer. This should be one
or two people who are familiar with the database and who interface well with the programmer. Once approved
by the Engineering Review Board, the focal point writes or rewrites the requirements to ensure the programmer
easily understands them. The change/enhancement is added to the users manual and if the
change/enhancement is substantial, training is scheduled.
Consider the importance of your testing approach. For the first four years, a separate test database was
maintained. Later, the test database was dropped because of the work required to maintain it. Testing is now
performed on the production database. This has been a cost-effective compromise that has resulted in few
bugs.
Make sure there is room to grow. In this case, text fields have grown from 20,000 characters to 65,000.
Other organizations may decide to use the database once it has proven itself. Also, the more you give users,
the more they seem to want.
Sponsorship can make it easier. Once senior management saw the benefit of using a standard process, a
single PR, and a single database, EP no longer had to maintain separate requirements, processes, procedures,
and updates.
Technology improvements can make it easier. By providing pull-down and pop-up lists within the PR fields,
diverse users could live with the generic PR.
Training is essential to the effectiveness of the database and the user. It saves users hours of time by not
having to struggle with an unknown element, and gives them hands-on experience.
Help lines and training manuals are important in helping users further understand what they are expected
to do. Help lines appear throughout most of the screens to inform and ensure that the PR is completed
accurately. The training manual for this database is set up for step-by-step instructions with visual aids.
Summary
Boeing's need for a CM database has been outlined. Defining the database requirements in specific terms for
design and implementation presented some challenges. The implementation presented user interface
challenges. The system has evolved to meet new requirements and to exploit new technology.
About the Author
Susan C. Grosjean is a configuration management specialist with the Electronic Products Group. She has 20
years of configuration management experience at Boeing. Prior to developing the database described in this
article, she developed status accounting databases for the B1-B and B2 bombers.
Boeing Commercial Airplane Group
P.O. Box 3707, No. MS OU-47
Seattle, Wash. 98124-2207
425-266-3731
Susan.Grosjean@PSS.Boeing.com
Notes
1. Electrical and electronic devices in aviation, including the software embedded in those devices.
2. For BCAG, the 777 airplanes represented an unprecedented software challenge in terms of the size and
complexity of the airplane's systems. The 2.5 million lines of newly developed software were approximately
six times more than any previous Boeing commercial airplane development program. Including
commercial-off-the- shelf and optional software, the total size is more than 4 million lines of code. This
software was implemented in 79 different systems produced by various suppliers throughout the world.
CrossTalk January 1996, "Software Development for the Boeing 777."
3. Line replaceable unit is the terminology for the circuit board, drawer, or cabinet that can be removed and
replaced when hardware failure occurs.
4. Class I Changes are called Engineering Change Proposals (ECPs) and consist of changes that are so
extensive that additional customer funds must be contracted to implement the change. Changes smaller
that Class I are called Class II.
Copyright: The Art of Service Pty Ltd, 2003
45
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
6 Security Management
6.1 Introduction
Business processes can no longer operate without a supply of information. In fact, more
and more business processes consist purely of one or more information systems.
Information Security Management is an important activity, which aims to control the
provision of information, and to prevent unauthorised use of information. For many
years, Information Security Management was largely ignored. However, this is changing.
Security is now considered as one of the main management challenges for the coming
years. The interest in this discipline is increasing because of the growing use of the
Internet and e-commerce in particular.
More and more businesses are opening electronic gateways into their business. This
introduces the risk of intrusion. What risks do we want to cover, and what measures
should we take now and in the next budgeting round? Senior Management has to take
decisions and these decisions can only be taken if a thorough risk analysis is undertaken.
This analysis should provide input to Security Management to determine the security
requirements. These requirements affect IT service providers and should be laid down in
Service Level Agreements. Security Management aims to ensure that the security
aspects of services are provided at the level agreed with the customer at all times.
Security is now an essential quality aspect of management. Security Management
integrates security in the IT organisation from the service provider’s point of view. The
Code of Practice for Information Security Management (BS 7799) provides guidance for
the development, introduction and evaluation of security measures.
6.1.1 Basic concepts
Security Management comes under the umbrella of Information Security, which aims to
ensure the safety of information. Safety refers to not being vulnerable to known risks,
and avoiding unknown risks where possible. The tool to provide this is security. The aim
is to protect the value of the information. This value depends on confidentiality, integrity
and availability.



Confidentiality: protecting information against unauthorised access and use.
Integrity: accuracy, completeness and timeliness of the information.
Availability: the information should be accessible at any agreed time.
This depends on the continuity provided by the information processing systems.
Secondary aspects include privacy (confidentiality and integrity of information relating
to individuals), anonymity, and verifiability (being able to verify that the information is
used correctly and that the security measures are effective).
6.2 Objectives
In recent decades, almost all businesses have become more dependent on information
systems. The use of computer networks has also grown, not only within businesses but
also between them, and between businesses and the world outside. The increasing
complexity of IT infrastructure means that businesses are now more vulnerable to
technical failures, human error, intentional human acts, hackers and crackers, computer
viruses, etc. This growing complexity requires a unified management approach. Security
Management has important ties with other processes. Other ITIL processes, under the
supervision of Security Management, carry out some security activities.
Security Management has two objectives:
Copyright: The Art of Service Pty Ltd, 2003
46
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0


To meet the security requirements of the SLAs and other external requirements
further to contracts, legislation and externally imposed policies.
To provide a basic level of security, independent of external requirements Security
Management is essential to maintaining the uninterrupted operation of the IT
organisation.
It also helps to simplify Information Security Service Level Management, as it is much
more difficult to manage a large number of different SLAs than a limited number.
The process input is provided by the SLAs, which specify security requirements, possibly
supplemented by policy documents and other external requirements. The process also
receives information about relevant security issues in other processes, such as security
incidents. The output includes information about the achieved implementation of the
SLAs, including exception reports and routine security planning.
At present, many organisations deal with Information Security at the strategic level in
information policy and information plans, and at the operational level by purchasing tools
and other security products. Insufficient attention is given to the active management of
Information Security, the continuous analysis and translation of policies into technical
options, and ensuring that the security measures continue to be effective when the
requirements and environment change. The consequence of this missing link is that, at
the tactical management level, significant investments are made in measures that are no
longer relevant, at a time when new, more effective measures ought to be taken.
Security Management aims to ensure that effective Information Security measures are
taken at the strategic, tactical and operational levels.
6.2.1 Benefits
Information Security is not a goal in itself; it aims to serve the interests of the business
or organisation. Some information and information services will be more important to the
organisation than others. Information Security must be appropriate to the importance of
the information. Striking a balance between security measures and the value of the
information, and threats in the processing environment develops tailor-made security.
An effective information supply, with adequate Information Security is important to an
organisation for two reasons:
 Internal reasons: an organisation can only operate effectively if correct and
complete information is available when required. The level of Information Security
should be appropriate for this.
 External reasons: the processes in an organisation create products and services,
which are made available to the market or society, to meet defined objectives. An
inadequate information supply will lead to substandard products and services,
which cannot be used to meet the objectives and which will threaten the survival
of the organisation. Adequate Information Security is an important condition for
having an adequate information supply. The external significance of Information
Security is therefore determined in part by the internal significance. Security can
provide significant added value to an information system. Effective security
contributes to the continuity of the organisation and helps to meet its objectives.
6.3 Process
Organisations and their information systems change. Checklists such as the Code of
Practice for Information Security Management are static and insufficiently address rapid
changes in IT. For this reason, Security Management activities must be reviewed
continuously to ensure their effectiveness. Security Management amounts to a neverending cycle of plan, do, check, and act. The activities undertaken by Security
Management, or undertaken in other processes under the control of Security
Management are discussed below. The security section of the Service Level Agreement
defines these requirements in terms of the security services and the level of security to
be provided.
Copyright: The Art of Service Pty Ltd, 2003
47
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
The service provider communicates these agreements to his organisation in the form of a
Security Plan, defining the security standards or Operational Level Agreements. This plan
is implemented, and the implementation is evaluated. The plan and its implementation
are then updated. Service Level Management reports about these activities to the
customer. Thus, the customer and the service provider together form a complete cyclical
process. The customer can modify his requirements on the basis of the reports. And the
service provider can adjust the plan or its implementation on the basis of these
observations, or aim to change the agreements defined in the SLA.
Diagram: The Security Management Cycle
6.4 Activities
6.4.1 Control - Information Security policy and organisation
The Control activity in the centre of diagram above is the first activity of Security
Management and relates to the organisation and management of the process. This
includes the Information Security management framework. This framework describes the
sub processes: the definition of security plans, their implementation, evaluation of the
implementation, and incorporation of the evaluation in the annual security plans (action
plans). The reports provided to the customer, via Service Level Management, are also
addressed. This activity defines the sub processes, security functions, and roles and
responsibilities. It also describes the organisational structure, reporting arrangements,
Copyright: The Art of Service Pty Ltd, 2003
48
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
and line of control (who instructs who, who does what, how is the implementation
reported).
The following measures from the Code of Practice are implemented by this activity.
Policy:
 Policy development and implementation, links with other policies.
 Objectives, general principles and significance.
 Description of the sub processes.
 Allocating functions and responsibilities for sub processes.
 Links with other ITIL processes and their management.
 General responsibility of personnel.
 Dealing with security incidents.
Information Security organisation:
 Management framework.
 Management structure (organisational structure).
 Allocation of responsibilities in greater detail.
 Setting up an Information Security Steering Committee.
 Information Security coordination.
 Agreeing tools (e.g. for risk analysis and improving awareness).
 Description of the IT facilities authorisation process, in consultation with the
customer.
 Specialist advice.
 Cooperation between organisations, internal and external communications.
 Independent EDP audit.
 Security principles for access by third parties.
 Information Security in contracts with third parties.
6.4.2 Plan
The Planning activity includes defining the security section of the SLA in consultation with
Service Level Management, and the activities in the Underpinning Contracts related to
security. The objectives in the SLA, which are defined in general terms, are detailed and
specified in the form of an Operational Level Agreement. An OLA can be considered as
the security plan for an organisational unit of the service provider, and as a specific
security plan, for example for each IT platform, application and network. The Planning
activity not only receives input from the SLA but also from the service provider's policy
principles (from the Control activity). Examples of these principles include: ‘Every user
should be uniquely identifiable’, and ‘A basic security level is provided to all customers,
at all times.’ The Operational Level Agreements for Information Security (specific security
plans) are drafted and implemented using the normal procedures. This means that,
should activities be required in other processes, there will have to be coordination with
these processes. Change Management using input provided by Security Management
makes any required Changes to the IT infrastructure. The Change Manager is responsible
for the Change Management process. The Planning activity is discussed with Service
Level Management to define, update and comply with the security section of the SLA.
The Service Level Manager is responsible for this coordination. The SLA should define the
security requirements, where possible in measurable terms. The customer's security
requirements and standards have to be verified, realistic and achievable.
6.4.3 Implement
The Implementation sub process aims to implement all the measures specified in the
plans.
The following checklist can support this activity.
Classification and management of IT resources:
Copyright: The Art of Service Pty Ltd, 2003
49
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0


Providing input for maintaining the CIs in the CMDB
Classifying IT resources in accordance with agreed guidelines
Personnel security:
 Tasks and responsibilities in job descriptions.
 Screening.
 Confidentiality agreements for personnel.
 Training.
 Guidelines for personnel for dealing with security incidents and observed security
weaknesses.
 Disciplinary measures.
 Increasing security awareness.
Managing security:
 Implementation of responsibilities, implementation of job separation.
 Written operating instructions.
 Internal regulations.
 Security should cover the entire life cycle; there should be security guidelines for
system development, testing, acceptance, operations, maintenance and phasing
out.
 Separating the development and test environments from the production
environment.
 Procedures for dealing with incidents (handled by Incident Management).
 Implementation of recovery facilities.
 Providing input for Change Management.
 Implementation of virus protection measures.
 Implementation of management measures for computers, applications, networks
and network services.
 Handling and security of data media.
Access control:
 Implementation of access and access control policy.
 Maintenance of access privileges of users and applications to networks, network
services, computers, and applications.
 Maintenance of network security barriers (firewalls, dial-in services, bridges and
routers).
 Implementation of measures for the identification and authentication of computer
systems, workstations and PCs on the network.
6.4.4 Evaluate
An independent evaluation of the implementation of the planned measures is essential.
This evaluation is needed to assess the performance and is also required by customers
and third parties. The results of the Evaluation activity can be used to update the agreed
measures in consultation with the customers, and also for their implementation. The
results of the evaluation may suggest changes, in which case an RFC is defined and
submitted to the Change Management process.
There are three forms of evaluation:
 Self-assessments: primarily implemented by the line organisation of the
processes.
 Internal audits: undertaken by internal EDP auditors.
 External audits: undertaken by external EDP auditors.
Unlike self-assessments, the same personnel that act in the other sub processes do not
undertake audits. This is to ensure that the responsibilities are separated.
Copyright: The Art of Service Pty Ltd, 2003
50
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Evaluations are also carried out in response to security incidents.
The main activities are:
 Verifying compliance with the security policy and implementation of security
plans.
 Performing security audits on IT systems.
 Identifying and responding to inappropriate use of IT resources.
 Undertaking the security aspects of other EDP audits.
6.4.5 Maintenance
Security requires maintenance, as risks change due to changes in the IT infrastructure,
organisation and business processes. Security maintenance includes the maintenance of
the security section of the SLA and maintenance of the detailed security plans.
Maintenance is carried out on the basis of the results of the Evaluation activity and an
assessment of changes in the risks. These proposals can either be introduced into the
Planning activity, or included in the maintenance of the SLA as a whole. In either case,
the proposals can result in including activities in the annual security plan. Any changes
are subject to the normal Change Management process.
6.4.6 Reporting
Reporting is not a activity, but an output of the other sub processes. Reports are
produced to provide information about the achieved security performance and to inform
the customers about security issues. These reports are generally required under
agreement with the customer.
Reporting is important, both to the customer and to the service provider. Customers
must be informed correctly about the efficiency of the efforts (e.g. with respect to
implementing security measures), and the actual security measures. The customer is
also informed about any security incidents.
A list with some suggestions for reporting options is included below.
Examples of scheduled reports and reportable events:
The Planning activity
 Reports about the extent of compliance with the SLA and agreed Key Performance
Indicators for security.
 Reports about Underpinning Contracts and any problems associated with them.
 Reports about Operational Level Agreements (internal security plans) and the
provider's own security principles (e.g. in the baseline).
 Reports about annual security plans and action plans.
The Implementation activity
 Status reports about the implementation of Information Security. This includes
progress reports about the implementation of the annual security plan, possibly a
list of measures which have been implemented or are yet to be implemented,
training, outcome of additional risk analyses, etc.
 A list of security incidents and responses to these incidents, optionally a
comparison with the previous reporting period.
 Identification of incident trends.
 Status of the awareness programme.
The Evaluation activity
 Reports about the sub process as such.
 Results of audits, reviews, and internal assessments.
 Warnings, identification of new threats.
Copyright: The Art of Service Pty Ltd, 2003
51
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Specific reports
To report on security incidents defined in the SLA, the service provider must have a
direct channel of communication to a customer representative (possibly the Corporate
Information Security Officer) through the Service Level Manager, Incident Manager or
Security Manager. A procedure should also be defined for communication in special
circumstances.
Apart from the exception in the event of special circumstances, reports are
communicated through Service Level Management.
6.4.7 Relationships with other processes
Security Management has links with the other ITIL processes. This is because the other
processes undertake security-related activities. These activities are carried out in the
normal way, under the responsibility of the relevant process and process manager.
However, Security Management gives instructions about the structure of the securityrelated activities to the other processes. Normally, these agreements are defined after
consultation between the Security Manager and the other process managers.
Configuration Management
In the context of Information Security, Configuration Management is primarily relevant
because it can classify Configuration Items. This classification links the CI with specified
security measures or procedures.
The classification of a CI indicates its required confidentiality, integrity and availability.
This classification is based on the security requirements of the SLA. The customer of the
IT organisation determines the classification, as only the customer can decide how
important the information or information systems are to the business processes. The
customer bases the classification on an analysis of the extent to which the business
processes depend on the information systems and the information. The IT organisation
then associates the classification with the relevant CIs. The IT organisation must also
implement this set of security measures for each classification level. These sets of
measures can be described in procedures. Example: ‘Procedure for handling storage
media with personal data’. The SLA can define the sets of security measures for each
classification level. The classification system should always be tailored to the customer's
organisation. However, to simplify management it is advisable to aim for one unified
classification system, even when the IT organisation has more than one customer.
In summary, classification is a key issue. The CMDB should indicate the classification of
each CI. This classification links the CI with the relevant set of security measures or
procedure.
Incident Management
Incident Management is an important process for reporting security incidents. Depending
on the nature of the incident, security incidents may be covered by a different procedure
than other Incidents. It is therefore essential that Incident Management recognise
security incidents as such. Any Incident, which may interfere with achieving the SLA
security requirements, is classified as a security incident. It is useful to include a
description in the SLA of the type of Incidents to be considered as security incidents. An
Incident that interferes with achieving the basic internal security level (baseline) is also
always classified as a security incident. Incidents reports are generated not only by
users, but also by the management process, possibly on the basis of alarms or audit data
from the systems. It is clearly essential that Incident Management recognise all security
incidents. This is to ensure that the appropriate procedures are initiated for dealing with
security incidents. It is advisable to include the procedures for different types of security
incidents in the SLA plans and to practice the procedure. It is also advisable to agree a
procedure for communicating about security incidents. It is not unusual for panic to be
created by rumours blown out of proportion.
Copyright: The Art of Service Pty Ltd, 2003
52
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
Similarly, it is not unusual for damage to result from a failure to communicate in time
about security incidents. It is advisable to route all external communications related to
security incidents through the Security Manager.
Problem Management
Problem Management is responsible for identifying and solving structural security
failings. A Problem may also introduce a security risk. In that case, Problem Management
must involve Security Management in resolving the Problem. Finally, the solution or
workaround for a Problem or Known Error must always be checked to ensure that it does
not introduce new security problems. This verification should be based on compliance
with the SLA and internal security requirements.
Change Management
Change Management activities are often closely associated with security because Change
Management and Security Management are interdependent. If an acceptable security
level has been achieved and is managed by the Change Management process, then it can
be ensured that this level of security will also be provided after Changes. There are a
number of standard operations to ensure that this security level is maintained. Each RFCs
is associated with a number of parameters, which govern the acceptance procedure. The
urgency and impact parameters can be supplemented by a security parameter. If an
RFCs can have a significant impact on Information Security then more extensive
acceptance tests and procedures will be required.
The RFCs should also include a proposal for dealing with security issues. Again, this
should be based on the SLA requirements and the basic level of internal security required
by the IT organisation. Thus, the proposal will include a set of security measures, based
on the Code of Practice.
Preferably, the Security Manager (and possibly also the customer’s Security Officer)
should be a member of the Change Advisory Board (CAB).
Nevertheless, the Security Manager need not be consulted for all Changes. Security
should normally be integrated with routine operations. The Change Manager should be
able to decide if they or the CAB need input from the Security Manager. Similarly, the
Security Manager need not necessarily be involved in the selection of measures for the
CIs covered by the RFCs.
This is because the framework for the relevant measures should already exist. Any
questions should only relate to the way in which the measures are implemented.
Any security measures associated with a Change should be implemented at the same
time as the Change itself, and be included in the tests. Security tests differ from normal
functional tests. Normal tests aim to investigate if defined functions are available.
Security tests not only address the availability of security functions, but also the absence
of other, undesirable functions as these could reduce the security of the system.
In terms of security, Change Management is one of the most important processes. This is
because Change Management introduces new security measures in the IT infrastructure,
together with Changes to the IT infrastructure.
Release Management
All new versions of software, hardware, data communications equipment, etc. should be
controlled and rolled out by Release Management. This process will ensure that:






The correct hardware and software are used.
The hardware and software are tested before use.
The introduction is correctly authorised using a Change.
The software is legal.
The software is free from viruses and that viruses are not introduced during its
distribution.
The version numbers are known, and recorded in the CMDB by Configuration
Management.
Copyright: The Art of Service Pty Ltd, 2003
53
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0

The rollout is managed effectively.
This process also uses a regular acceptance procedure, which should include Information
Security aspects. It is particularly important to consider security aspects during testing
and acceptance. This means that the security requirements and measures defined in the
SLA should be complied with at all times.
Service Level Management
Service Level Management ensures that agreements about the services to be provided to
customers are defined and achieved. The Service Level Agreements should also address
security measures. The objective is to optimise the level of service provided.
Service Level Management includes a number of related security activities, in which
Security Management plays an important role:
1. Identification of the security needs of the customer. Naturally, determining the
security needs is the responsibility of the customer as these needs are based on their
business interests.
2. Verifying the feasibility of the customer's security requirements.
3. Proposing, discussing and defining the security level of the IT services in the SLA.
4. Identifying, developing and defining the internal security requirements for IT services
(Operational Level Agreements).
5. Monitoring the security standards (OLAs).
6. Reporting on the IT services provided.
Security Management provides input and support to Service Level Management for
activities 1 - 3. Security Management carries out activities 4 and 5. Security Management
and other processes provide input for activity 6. The Service Level Manager and the
Security Manager decide in consultation that actually undertakes the activities.
When defining an SLA it is normally assumed that there is a general basic level of
security (baseline). Additional security requirements of the customer should be clearly
defined in the SLA.
Availability Management
Availability Management addresses the technical availability of IT components in relation
to the availability of the service. The quality of availability is assured by continuity,
maintainability and resilience. Availability Management is the most important process
related to availability. As many security measures benefit both availability and the
security aspects confidentiality and integrity, effective coordination of the measures
between Availability Management, IT Service Continuity Management, and Security
Management is essential.
Capacity Management
Capacity Management is responsible for the best possible use of IT resources, as agreed
with the customer. The performance requirements are based on the qualitative and
quantitative standards defined by Service Level Management. Almost all Capacity
Management activities affect availability and therefore also Security Management.
IT Service Continuity Management
IT Service Continuity Management ensures that the impact of any contingencies is
limited to the level agreed with the customer. Contingencies need not necessarily turn
into disasters. The major activities are defining, maintaining, implementing, and testing
the contingency plan, and taking preventive action. Because of the security aspects,
there are ties with Security Management. On the other hand, failure to fulfil the basic
security requirements may be considered itself as a contingency.
Copyright: The Art of Service Pty Ltd, 2003
54
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
6.4.8 Security section of the Service Level Agreement
The Service Level Agreement (SLA) defines the agreements with the customer. The
Service Level Management process is responsible for the SLA. The SLA is the most
important driver for all ITIL processes. The IT organisation indicates to what extent the
requirements of the SLA are achieved, including security requirements. The security
elements addressed in the SLA should correspond to the security needs of the customer.
The customer should identify the significance of all business processes. These business
processes depend on IT services, and therefore on the IT organisation. The customer
determines the security requirements on the basis of a risk analysis. The security
elements are discussed between the representative of the customer and the
representative of the service provider. The service provider compares the customer's
Service Level Requirements with their own Service Catalogue, which describes their
standard security measures (the Security Baseline). The customer may have additional
requirements. The customer and provider compare the Service Level Requirements and
the Service Catalogue. The security section of the SLA can address issues such as the
general Information Security policy, a list of authorised personnel, asset protection
procedures, restrictions on copying data, etc.
6.4.9 The Security section of the Operational Level Agreement
The Operational Level Agreement is another important document. It describes the
services provided by the service provider. The provider must associate these agreements
with responsibilities within the organisation. The Service Catalogue gives a general
description of the services. The Operational Level Agreement translates these and
general descriptions into all services and their components, and the way in which the
agreements about the service levels are assured within the organisation.
Example: the Service Catalogue refers to ‘managing authorisations per user and per
individual’. The Operational Level Agreements details this for all relevant services
provided by the IT organisation. In this way, the implementation of the measure is
defined for the departments providing UNIX, VMS, NT, Oracle services, etc. Where
possible, the customer's Service Level Requirements are interpreted in terms of the
provider's Service Catalogue, and additional agreements are concluded where necessary.
Such additional measurements exceed the standard security level. When drafting the
SLA, measurable Key Performance Indicators (KPI) and criteria must also be agreed for
Security Management. KPIs are measurable parameters (metrics), and performance
criteria are set at achievable levels. In some cases it will be difficult to agree on
measurable security parameters. This is easier for availability, which can generally be
expressed numerically. However, this is much more difficult for integrity and
confidentiality. For this reason, the security section of the SLA normally describes the
required measures in abstract terms. The Code of Practice for Information Security
Management is used as a basic set of security measures. The SLA also describes how
performance is measured. The IT organisation (service provider) must regularly provide
reports to the user organisation (customer).
6.5 Process control
6.5.1 Critical success factors and performance indicators
The critical success factors are:
 Full management commitment and involvement.
 User involvement when developing the process.
 Clear and separated responsibilities.
The Security Management performance indicators correspond with the Service Level
Management performance indicators, in so far as these relate to security issues covered
by the SLA.
Copyright: The Art of Service Pty Ltd, 2003
55
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
6.5.2 Functions and roles
In small IT organisations, one person may manage several processes. While in large
organisations, several persons will be working on one process, such as Security
Management. In this case there is normally one person appointed as Security Manager.
The Security Manager is responsible for the effective operation of the Security
Management process. Their counterpart in the customer's organisation is the Information
Security Officer, or Corporate Information Security Officer.
6.6 Points of Attention and costs
As with any process there are areas that could undermine the successful implementation.
The following section details some of the areas that must be covered to make the
process implementation worthwhile.
The final section looks briefly at some of the cost areas when it comes to the introduction
of Security Management.
6.6.1 Points of attention
The following issues are essential to the successful implementation of Security
Management:
 Commitment: security measures are rarely accepted immediately, resistance is
more common than acceptance. Users resent losing certain privileges due to
security measures, even if these facilities are not essential to their work. This is
because the privileges give them a certain status. A special effort will therefore
have to be made to motivate users, and to ensure that management complies
with the security measures. In the field of Security Management in particular,
management must set an example (‘walk the talk’ and ‘lead by example’). If there
are no security incidents, then management may be tempted to reduce the
Security Management budget.
 Attitude: information systems are not insecure due to technical weaknesses, but
due to the failure to use the technology. This is generally related to attitude and
human behaviour. This means that security procedures must be integrated with
routine operations.
 Awareness: awareness, or rather communication, is a key concept. There
sometimes appears to be a conflict of interest between communication and
security – communication paves the road, while security creates obstacles. This
means that implementing security measures requires the use of all
communication methods to ensure that users adopt the required behaviour.
 Verification: it should be possible to check and verify security. This concerns
both the measures introduced, and the reasons for taking these measures. It
should be possible to verify that the correct decisions have been taken in certain
circumstances. For example, it should also be possible to verify the authority of
the decision-makers.
 Change Management: frequently the verification of continued compliance with
the basic level of security wanes over time when assessing Changes.
 Ambition: when an organisation wants to do everything at once, mistakes are
often made. When introducing Security Management, the implementation of
technical measures is much less important than organisational measures.
Changing an organisation requires a gradual approach and will take a long time.
 Lack of detection systems: new systems, such as the Internet, were not
designed for security and intruder detection. This is because developing a secure
system takes more time than developing a non-secure system, and conflicts with
the business requirements of low development costs and a short time-to-market.
Copyright: The Art of Service Pty Ltd, 2003
56
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
6.6.2 Costs
Securing the IT infrastructure demands personnel, and therefore money, to take,
maintain and verify measures. However, failing to secure the IT infrastructure also costs
money (cost of lost production; cost of replacement; damage to data, software, or
hardware; loss of reputation; fines or compensation relating to failure to fulfil contractual
obligations). As always, a balance will have to be struck.
Copyright: The Art of Service Pty Ltd, 2003
57
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
EXTRA READING
Central Command Releases Its Annual Computer Security Survey Results for 2002
Virus protection concerns continue to increase among P2P users; Cyber-warfare likely according to
respondents
MEDINA, Ohio, September 24, 2002 - Central Command, Inc., a leading provider of PC anti-virus software and
computer security services announced today the findings of its annual security survey. The survey, reflecting
up-to-date industry trends, was e-mailed to 943,026 PC users worldwide and explored individual's computer
security settings and behaviours with known computer security vulnerabilities. With a 7% response rate, the
survey provides valuable insight on the constant battle with computer viruses.
Given the horrific events of September 11, 2001, multiple questions were given seeking user opinion on the
world's war on terror in regards to online security. The survey surprisingly showed that nearly three-fourths of
the respondents felt that some form of cyber-warfare is likely to occur in the near future. In a related question,
67% strongly feel that their respective country is not yet prepared to combat against such a major threat. The
top response rate came out of North America.
The results also displayed a significant increase in virus awareness. For the first time, responses showed that
users are beginning to understand the importance of protecting themselves from computer viruses and other
forms of malicious software (malware).
When asked about the handling of email attachments from an unknown source, the results showed that 58% of
the respondents would delete the attachment immediately and 41% expressed they practiced extreme caution
when viewing any attachment regardless of the sender. "These numbers mark a great improvement from a
year ago. We have relentlessly preached about the risks associated with email attachments and we're finally
seeing that message sticking in users minds. Unfortunately, the lesson doesn't end with email-based worms
as other types of applications are now being targeted," said Steven Sundermeier, product manager at Central
Command, Inc. On a similar note, 29% claim to have all the latest security patches installed, up 15% from a
year ago.
As file-sharing applications like KaZaA, iMesh, Napster continue to increase in popularity so does the number of
malicious programs (ie. trojans, worms) written to exploit these networks. Of the 65% of surveyed users who
regularly use these types of applications, over 39% responded that they were unaware of any dangers
associated with file sharing and the security holes they can open. An increase in P2P instant messaging
software as the preferred form of online communication raised concern about the future of virus writing trends
in these channels.
The number one reported virus, according to the survey, was Worm/Klez.E,G. Nearly one-forth of home and
office PC users responding claimed Klez infected their system over the last year. One in every ten responses
claimed to have had a W32/Nimda infection. "This statistic closely mirrors the number of virus occurrences
confirmed through our Emergency Virus Response Team. Based on the percentage of all tracked viruses, our
top five tracked viruses for the summer of 2002 included Worm/Klez.E,G (52.1%), W32/Elkern.C (13.8%),
W32/Yaha.E (9.6%), Worm/W32.Sircam (5.7%), and W32/Nimda (2.4%)."
Central Command noted that over the past year infection reports, factoring out the top five infectors, have
dropped 3.2% over the past year.
The full results of the survey are published on Central Command's website at:
http://www.centralcommand.com/safesurvey2002.html
Vexira Antivirus starts at $29.95, and a free 30-day trial version may be downloaded by clicking here or
obtained by contacting Central Command at +1-330 723-2062.
About Central Command: A leader in the anti-virus industry, Central Command, Inc., a privately held company,
serves home PC users and industrial, financial, government, education and service firms with virus protection
software, services, and information. The company services customers in over 91 countries and is
headquartered in Medina, Ohio. Visit Central Command online at (www.centralcommand.com) or call 1-330723-2062 for more information.
Central Command, EVRT, Vexira, and Emergency Virus Response Team are trademarks of Central Command,
Inc. All other trademarks, trade names, and products referenced herein are property of their respective owners.
Copyright: The Art of Service Pty Ltd, 2003
58
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
7
IT Service Management Tools
Every IT organisation uses tools to support its ability to deliver services and perform
processes. The type of tool you need, is dependent on what you want to get out of it.
For small organisations, the tool can be an Excel Spreadsheet. For larger organisations,
there are a great number of commercial tools to select from.
Try to design your processes before you start looking for a tool. This gives you the
opportunity to really do a thorough Functional and technical specification before talking
to the vendors.
A lot of research can be done using the Internet. Many (tool) vendors have a list of
appropriate tools listed with the specifications.
7.1.1 Type of tools
There are many tools on the market. The following list gives an example of some of the
tools that organisations use:
Service Desk Tools / Support Tools
o Heat
o Infra
o Peregrine Service Centre
o Remedy
System Management tools
o HP Openview
o Qualiparc
o CA Unicentre
7.1.2 The Cost of a Tool
When you have decided on a tool, you really need to have a close look at the cost. Most
of the expenses are in getting the tool to work for you, the way you want it to.
The following are some examples of the implementation cost of any tool:








Initial Purchase Price
Additional Licenses
Maintenance contract
Warranty
Training of staff in using the tool
Implementation expenses (consultancy hours)
Fine-tuning the tool to your needs (consultancy and engineering hours)
Updating the internal processes to fit the tool (consultancy and internal staff
hours)
Copyright: The Art of Service Pty Ltd, 2003
59
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
Version 5.0
EXTRA READING
Field notes: Choosing a tool that fits.
Varian Semiconductor Equipment Associates Inc. has plants in more than 40 locations in the U.S., Europe and
the Far East, but the Gloucester, Mass.-based manufacturer had no way to monitor connections between
facilities, says Troy Preble, manager of networks and technology.
"Limited visibility meant managing the network whenever users called," says Preble.
The company investigated several options, including outsourcing and using management framework products
from IBM's Tivoli and HP before deciding on the WebNM network management suite from Somix Technologies
Inc. in Sanford, Maine.
Installing the suite took three days, including two spent on training. Immediately, Varian discovered one T1 line
constantly operating at full capacity and an overprovisioned connection to Japan, which was running at less
than 60% of capacity. Varian added a second T1 and cut back on the international line, drastically cutting costs
and improving service.
In addition to monitoring WAN connections, Varian also uses WebNM to monitor server uptime, performance
statistics, hard-drive and CPU utilization, as well as monitoring all switches and routers.
Preble acknowledges that WebNM doesn't have the full range of features available in a package from one of the
big network management framework vendors but says the package met all of Varian's needs at a lower cost.
"For what we wanted to do, WebNM cost one-tenth what we would have spent on Tivoli or OpenView," he says.
Source: Computerworld
Copyright: The Art of Service Pty Ltd, 2003
60
Version 5.0
GPO 2673
Brisbane, QLD 4001
Australia
Phone: 1300 13 44 99
This page left blank.
61