Foundation Gui Dev 1

8/8/2019 Foundation Gui Dev 1

1/91

IT Service Success

FOUNDATIONSTUDY GUIDE

2006 IT Service Success 1


2/91

The Foundations of IT Service Management

IT Service Success

FOUNDATION STUDY GUIDE.............................................................................1The Foundations of IT Service Management...................................................2The Importance of IT Service Management.....................................................6What is IT Service Management? ...................................................................7Why use ITIL? .................................................................................................9What exactly is ITIL?.....................................................................................11

Benefits of ITIL explored................................................................................13Additional benefits of adopting ITIL:...................................................14

ITIL Processes................................................................................................151 Service Desk..............................................................................................15

1.1 Function........................................................................................151.2 Mission..........................................................................................151.3 Goals.............................................................................................161.4 Benefits.........................................................................................171.5 Understanding the customer / user..............................................171.6 Organization.................................................................................171.7 Staffing.........................................................................................181.8 Structure.......................................................................................18

1.9 Tools.............................................................................................201.10 Metrics........................................................................................211.11 Challenges..................................................................................22

2 Incident Management................................................................................232.1 Mission..........................................................................................232.2 Goals.............................................................................................232.3 Definition......................................................................................232.4 Scope............................................................................................242.5 Benefits.........................................................................................242.6 Process.........................................................................................242.7 Incident Classification ..................................................................252.8 Escalation.....................................................................................25

2.9 Incident Manager Responsibility...................................................262.10 Tools...........................................................................................262.11 Metrics........................................................................................272.12 Challenges..................................................................................29

3 Problem Management................................................................................303.1 Mission..........................................................................................303.2 Goals.............................................................................................303.3 Definition......................................................................................30



3/91

3.4 Process.........................................................................................313.5 Benefits.........................................................................................313.6 Relationship between Incident, Problem, Known Errors and

Changes...............................................................................................323.7 Reactive Problem Management....................................................333.8 Proactive Problem Management...................................................333.9 Common Techniques....................................................................343.10 Major Problem Reviews...............................................................343.11 Tools...........................................................................................343.12 Metrics........................................................................................353.13 Challenges..................................................................................35

4 Change Management.................................................................................364.1 Mission..........................................................................................364.2 Goals.............................................................................................364.3 Why Change Management?..........................................................374.4 Benefits.........................................................................................374.5 Change Categories........................................................................394.6 Key Roles......................................................................................404.7 Process.........................................................................................424.8 Tools.............................................................................................444.9 Metrics..........................................................................................444.10 Challenges..................................................................................45

5 Configuration Management........................................................................465.1 Mission..........................................................................................465.2 Goals.............................................................................................465.3 Definitions.....................................................................................465.4 Scope............................................................................................475.5 Benefits.........................................................................................485.6 Process.........................................................................................495.7 Relationships with other Processes...............................................495.8 Key Terms.....................................................................................505.9 Configuration Manager's Responsibilities.....................................525.10 Tools...........................................................................................525.11 Metrics........................................................................................545.12 Challenges..................................................................................56

6. Release Management ................................................................................ 586.1 Context.........................................................................................586.2 Mission..........................................................................................586.3 Goals.............................................................................................586.4 Appropriateness............................................................................596.5 Key Terms.....................................................................................596.6 Relationship to Configuration Management..................................606.7 Scope............................................................................................616.8 Benefits.........................................................................................61

6.9 Process.........................................................................................626.10 Release Management's Responsibilities.....................................636.11 Integrated Plans..........................................................................636.12 Tools...........................................................................................646.13 Metrics........................................................................................646.14 Challenges..................................................................................64

7 Capacity Management...............................................................................667.1 Mission..........................................................................................66

The Mission of Capacity Management is to: .......................................66



4/91

Understand the organizations operation and IT infrastructure toensure that all current and future capacity and performance aspects ofthe business requirements are provided cost effectively at the righttime ....................................................................................................66Effective Capacity Management means "No Surprises!" .....................66

7.2 Goals.............................................................................................667.3 Scope............................................................................................66

This scope covers three core areas: ...................................................67

7.4 Benefits.........................................................................................677.5 Process.........................................................................................677.6 Capacity Manager's Responsibilities.............................................687.7 Capacity Database........................................................................687.8 Tools.............................................................................................697.9 Metrics..........................................................................................697.10 Challenges..................................................................................71

8 Availability Management ..................................................................728.1 Mission..........................................................................................728.2 Goals.............................................................................................728.3 Scope............................................................................................728.4 Key Terms.....................................................................................73

8.5 Benefits.........................................................................................738.6 Techniques....................................................................................748.7 Process.........................................................................................768.8 Tools.............................................................................................778.9 Metrics..........................................................................................778.10 Challenges..................................................................................78

9 IT Service Continuity..................................................................................799.1 Mission..........................................................................................799.2 Goals............................................................................................799.3 Scope............................................................................................799.4 Benefits.........................................................................................809.5 Process.........................................................................................80

9.6 Metrics..........................................................................................819.7 Challenges....................................................................................81

10 Service Level Management......................................................................8210.1 Mission........................................................................................8210.2 Goals...........................................................................................8210.3 Scope..........................................................................................8310.4 Benefits.......................................................................................8310.5 Process.......................................................................................8410.6 SLA Content................................................................................8410.7 Tools...........................................................................................8510.8 Metrics........................................................................................8510.9 Challenges..................................................................................85

11 Security Management..............................................................................8611.1 Mission........................................................................................8611.2 Scope..........................................................................................8611.3 Benefits.......................................................................................8611.4 Process.......................................................................................8711.5 Relationships with other disciplines............................................8711.6 Metrics........................................................................................8811.7 Challenges..................................................................................88



5/91

Organizations That Promote ITIL ..................................................................89ITSMF............................................................................................................90THOMPSON PROMETRIC................................................................................91Thomson Prometric is the recognized global leader in testing and

assessment services, providing paper-and-pencil, Internet and computer-based testing solutions. It offers a fully integrated testing system thatincludes test development, test delivery and data management capabilities........................................................................................................................91Since 2002, Thomson Prometric and EXIN have collaborated on the delivery

of the ITIL Foundation exams in English. As a result, EXIN can improve theaccessibility of EXIN's IT Service Management (ITIL) exams for morecandidates worldwide, and test them in the highly secure, consistent

Thomson Prometric Testing Center environment, while providing candidateswith improved flexibility in choosing both the test date and location. .........91www.prometric.com......................................................................................91



6/91

The Importance of IT Service Management

Over the years the reliance on IT services has never been moreprevalent. As Businesses grow, the IT services they utilize and rely onbecome more complex, competitive. Alongside this the environmentshave become more regulated. IT Managers are challenged daily withthe co-ordination and working in partnership with the business tocontinuously deliver high quality IT services. IT Management isconcerned with the effective and efficient use of the four Ps :

With all this in mind a need has arisen for the creation of a standardset of practices to manage the IT services being delivered. As a resultof this requirement the Information Technology Infrastructure Library

(ITIL) was created.

ITIL is widely recognized throughout the world, and may well be themost widely accepted approach to managing and delivering IT servicestoday.

This guide will cover the following topics:

What is Service Management and its importance

What is ITIL?

Why organizations should use ITIL

The ITIL Processes

The basic concepts of ITIL

The benefits of ITIL

Organizations that promote ITIL

The ITIL framework

2006 IT Service Success

People

Products

Partners

Processes

6


7/91

This guide will provide you information on the above topics, in nontechnical, easy to understand terms with the objective being that uponcompletion of this document you will have a good understanding of ITILthat can be used a the basis for your ITIL Foundation LearningProgram.

What is IT Service Management?

IT Service Management is a top-down, business driven approach forthe management of IT that intentionally addresses the strategicbusiness value generated by the IT organization and the need todeliver a high quality IT service.

IT Service Management is designed to focus on the issues that ITorganizations face on a daily basis - the people, the processes and thetechnology issues.

Whilst IT Service Management as a concept is related to ITIL it is notthe same. When comparing the two, ITIL can be seen as an instance ofan ITSM framework, whilst also containing a subsection specificallyentitled IT Service Management.

IT Service Management within ITIL is the combination of the ServiceSupport and Service Delivery volumes. These are explained in more

http://en.wikipedia.org/wiki/IT_Service_Managementhttp://en.wikipedia.org/wiki/IT_Service_Management


8/91

detail later in the document.



9/91

Why use ITIL?

ITIL is popular because of the proven best practices that it offers. Thedemand for information about ITIL continues to grow. Among otherreasons for investigating ITIL recommendations, one commonmotivation is to learn about knowledge and best practices necessary

for achieving compliance with Sarbanes-Oxley and other IT governancerequirements. Another thing to consider is that ITIL is the onlyconsistent and comprehensive documentation of best practice for ITService Management.

Most IT-departments are event driven and operate in a reactiveenvironment, with day to day activity spent resolving issues, i.e.service unavailable. Not only are these situations frustrating, but theyare also costly. The choice to adopt and implement is in the majoritybased on the fact that the organization is able to understand better the

Total Cost of Ownership (TCO) and the actual activities undertakenwithin the IT-department.

ITIL provides a proven method for planning, processes, roles and thehow they interact and communicate.

There are a number of reasons why organizations choose to adopt ITIL?

The existing resources are failing to meet the needs of thebusiness demands & are becoming too expensive

The customers perceive the current service(s) being delivered aspoor quality & unreliable

Potential for audits to raise concerns regarding reducedaccountability & inability to be benchmarked.

Major incidents are impacting revenue and service restoration isbecoming timely and expensive.

To support strategic business objectives.

To support and initiate a restructure, consolidation & corporategovernance

To improve service based on proven Industry Best Practice &standards

Finally to improve service to customers and to stop re-inventingthe wheel

ITIL as with other model frameworks can provide an excellent structurethat companies and organizations can follow. Basically, employees can



10/91

work towards the same goals that are supported by a clear and specificstructure.



11/91

What exactly is ITIL?

Originally produced in the late 80s early 90s as a set of more than40 volumes, however, thankfully, this has now been reduced to a set of

six books that describe IT Service Management Best Practice. ITIL hasnow become the de-facto standard in Service Management and as itfocuses on the best practice it can be tailored according to need. Overthe years ITIL has now become relevant to all organizations, whetherthey be Public or Private sector.

The six volumes are:

Service Support Service Delivery Planning to implement Service Management ICT Infrastructure Management Applications Management The Business Perspective

The library is intended to assist organizations to provide high quality ITservices, whilst faced with the challenges of budgets, skill shortages,complexity of systems, rapid change and growth, current and futureuser / customers requirements and the ever growing challenge ofincreasing customer satisfaction.

Whilst the books offer guidance on the provision of quality IT services,with the focus being on quality, it is worth noting that the books alsooffer guidance on the accommodation and environmental facilitiesneeded to support IT.

The books are the only comprehensive, publicly availableguidance for IT service management.

The collections of volumes are produced by the OGC Office ofGovernment Commerce (previously known as CCTA).

The books are best practice guidelines describing the whatrather than the how.

Whilst the UK Government created ITIL via the CCTA, it is quickly beingadopted throughout the world as the standard for best practice in thedelivery of IT Services. The main focus of ITIL is the IT ServiceManagement (ITSM)



12/91

ITSM is divided into two main areas, Service Support and ServiceDelivery.

These two areas are made up of10 disciplines



13/91

Benefits of ITIL explored

Fact : IT is what drives businesses today!

The profitability and shareholder loyalty of an organization isdependent on the high availability, dependability, security andperformance of IT services. Thishas made the maturity or immaturity of IT management highly visible.

By improving the IT processes, the organization can begin to:

o Improve project deliverables and the time to deliver;

o Improve resource utilization;

o Reduce the need for rework;

o Improve availability, reliability and security of mission critical ITservices;

o Be more competitive in the market place;

o Justify to the business the cost of service quality;

o Provide services that meet business, customer and user

demandso Eliminate redundant work

o Integrate central processes

o Document and communicate roles and responsibilities in service

provisiono Learn from previous experience

o Measure the services offered and the customer satisfactionlinked to these services

o Provide demonstrable performance indicators

Some intangible Benefits of ITIL:

During the past decade, the reshaping of business functions asprocesses have become a well know and reputable strategy forreducing costs, reducing cycle times, and improving quality andcustomer satisfaction.

There is a growing appreciation that IT is a key driver of businessprocess improvement. This has led to a predictable change in theexpectations for the IS organization to follow the process changesoccurring within the finance, sales, marketing and manufacturingarenas.

In some cases, this has led to the formation of such organizational



14/91

structures as relationship managers, steering committees and usercouncils to improve the alignment of business and IT planning.

A further consequence of the change has been to look at functionallydisconnected IT activities as linked sets that share commoninformation and customers.

Other benefits include improved staff satisfaction as a result of clear

and defined processes.

Additional benefits of adopting ITIL:

o Aligns IT services to present and future needs of the business

and its customerso Better accessibility to services for users through single point of

contacto Speedy responses to customer enquiries and complaints

o Improved team work and communication

o Better identification of areas for improvement

o Pro-active approach to service provision

o More favorable perception of services provided

o Improved quality of IT-related information for optimal

management and decision-makingo Reduced impact on the companys business activities

o Better management and control over the IT systemsinfrastructureo More effective and efficient usage of resources related to service

provision and subsequent cost reduction potentialo Higher IT system users productivity due to reduced down times

o Improved first line resolution rates

o Enhanced customer care and higher customer satisfaction

o Improved control of SLA performance

o Strengthened IT infrastructure

o Eradicate loss and inconsistent records of information, incidents

and customer enquirieso Reduced numbers of incidentso Discovery and implementation of permanent solutions Reduced

expense in developing processes, procedures and instructionso Cost justifiable service quality

o Reduced costs due to centralized integrated processes

o Reduced costs due to learning from past experience

o Clearly defines functions, roles and responsibilities



15/91

o Improve the communication between the IT departments and its

customerso Everyone speaking to same language

o IT Services that meet the business, customer and user demands

o Improve customer satisfaction better measurements of

availability and performance of the IT serviceo Support the business processes and provide IT services that

meet the particular business requiremento Improve productivity and efficiency due to knowledge and

experienceo Improved employee satisfaction and potential to improve staff

retention levelso Professional training and qualifications for IT personnel

o Everyone speaking to same language

ITIL Processes

1 Service Desk

1.1 Function

Function - Not A Process!

The IT Service Desk is not a core ITIL Process it is in fact a function.However it is a very important function. Just because it is not classedas a process does not mean that the Service Desk is any less wellorganized, structured or controlled.

Service Desks need to have quality procedures, training programs,scripts, tools and controls to help assure its performance.

1.2 Mission

The Service Desk acts as the central point of contact between the User

and the IT Service Management Organization. The Service Deskhandles both Service Requests and Incidents. The Service Deskprovides an effective interface to other activities such as IncidentManagement, Problem Management, Change Management,Configuration Management, Release Management, Service LevelManagement and IT Service Continuity Management



16/91

1.3 Goals

The goals of the Service Desk are to:

o Provide a single point of contact between users and IT Service

Management.o Reduce costs by the efficient use of resources.

o Ensure long term user/customer satisfaction.

o Handle user requests effectively.

o Reduce the business impact of incidents.

o Provide management information and reports.



17/91

1.4 Benefits

The Service Desk will provide a number of benefits:

o Ease of accessibility, a known contact point that is always

available.o Central point of contact provides peace of mind that there's only

one place to communicate with the IT Service Organization whenreporting an Incident.

o Knowledgeable and helpful contact point, the user feels

confident that the right people and focus has been applied totheir Incident or Service Request.

o Useful 'filter', to prevent unnecessary Incidents (e.g. My PC's not

working - Is it switched on?) entering the IT Service Organization.o Provision of reports and management information to help

maintain agreed service levels with the business.

1.5 Understanding the customer / user

The Service Desk will ensure that they:

o Really know and understand the user community.

o Understand the business drivers.

o Understand the Services used.

o Appreciate the impact of failure and downtime.

o Manage location, language and cultural challenges.o Understand the management structure of the IT Service

Organization.o An intelligent contact point that is helpful and works on behalf of

the user.

1.6 Organization

The Service Desk must ensure that it's organized well to provide:

o Appropriate hours of coverage.o Levels of flexibility.

o Correct staffing levels.

o Appropriate skills provided.

o Appropriate knowledge.

o Suitable structure.



18/91

1.7 Staffing

Staff considerations to include:

o Systems and service understanding, technical awareness and

local business appreciation.o Know the business and IT Service Organizational structure and

understand the management hierarchy.o Interpersonal skills are vital to be efficient and effective.

o These include: empathy, ownership, drive, determination,

communication, patience and often language skills.

1.8 Structure

There are three well known structures for a Service Desk:

A "Local" Service Desk will support local business needs. It should befit for purpose and highly in tune with what the business users need.Operating standards and processes are required to maintain consistentquality of service.

A "Central" Service Desk supports multiple locations and sometimes

multiple geographies. The business is distributed. Centralizationprovides a consistent service experience. Standards are maintainedand staffing levels and expertise can be controlled easier. This usuallyleads to lower overall operating costs.

A "Virtual" Service Desk operation is location independent. SometimesService Desk Analysts work from home or across a number oflocations. This is more common in large multi-national organizationswhere multi-language assistance is required. Users feel like they arecommunicating locally. Standard operating practices, processes anduser experience must be upheld. Management of the "Virtual" Service

Desk is more challenging due to the complexity, time zone differenceand language differences. Usually a local or regional team leader ormanager is appointed to act as the leading representative.

In addition, many large Service Desks operate a "Follow the sun"Service. Here, "Follow the Sun" Service Desk Operations provide 24 X 7X 365 support for large organizations or multiple global contracts.Service Desk support is routinely 'switched' across time zones to



19/91

match the availability of staff. From a business perspective it is usuallycheaper to pay for staff between 0900 and 1700. Processes,procedures and standards for the ongoing ownership and escalation ofincidents and requests is more challenging.



20/91

1.9 Tools

An Integrated IT Service Management Tool is a must for any effectiveIT Services Organization. Such tools provide the capability to log anincident or service request, record progressive actions, apply time and

date stamps, automate escalation and notification events against thelogged item and provide management information reporting at varyinglevels.

The Tool must also be capable of providing workflow to enableindividual tickets to be worked across the many ITIL processes. Forexample an Incident ticket can be assigned to a support group forinvestigation and diagnosis.

An effective Service Desk may also utilize several other supportingtools to increase the level of user responsiveness and overall

automation. If these supporting tools are integrated (or interface with)the overarching IT Service Management tool - then overall levels ofinter-operability are enhanced.

Such tools include: Known Error Database, CMDB and DiagnosticScripts with Automated Resolution Actions. In addition, due to thevolume and frequency of calls received by any Service Desk, a suitablecall management system is typically required. Call managementsystems provide queuing capabilities, call routing and transfer,interactive voice response (IVR), and in more advanced casescomputer telephony integration (CTI) functionality. Again, if thisfunctionality is integrated within the overarching IT ServiceManagement Tool, then the overall control and visibility of ticketslogged will be considerably enhanced.



21/91

1.10 Metrics

Typical Service Desk Metrics Include:

o #calls taken,

o #incidents logged,o #service requests logged,

o #calls abandoned (user hangs up),

o #calls answered within xx seconds,

o average call duration, calls waiting

o #calls logged per Service Desk analyst.

More advanced Service Desk Metrics include:

o #calls resolved first time,

o

#calls passed to Support team x,o #times a call was re-assigned,

o age of a call,

o average age of a call

o and #calls resolved within Service Levels.

An important aspect of the Service Desk operation is Service Qualityand User Satisfaction. Feedback forms, sample call backs andworkshops are common methods for determining how well the ServiceDesk is performing and is an excellent way to learn how the ServiceDesk can improve further.

An Integrated IT Service Management Tool and Call Management toolsprovide the Service Desk with the capability of producing real-time andhistoric reports on a wide range of metrics. It is not the production ofthese reports that is important but the level of review, action anddecisions taken on the information provided that really counts.

The Service Desk Manager is responsible for the regular production ofmanagement information and reports that provide vital feedback onperformance and improvement activities for IT Service Management



22/91

1.11 Challenges

Typically the Service Desk faces many day to day, medium term andlong term challenges. Included in these, but not limited to, are:

o Staffing levels.

o Staff skills and capabilities.

o Dealing with peaks in call volume.o Managing high impacting incidents.

o Absorbing necessary information to be able to provide an

effective service.o Maintaining IT Service quality as the Organization becomes more

complex, the number of service increases or the Organizationchanges/grows.



23/91

2 Incident Management

2.1 Mission

The mission of Incident Management is to restore normalservice operation as quickly as possible with minimumbusiness disruption to ensure the best levels of availability andservice are maintained

Remember:

- Normal Service Operation - As Quickly as possible - Minimumdisruption - Best levels of availability.

2.2 Goals

The goals of Incident Management are to:

o Restore normal service operation

o Minimize adverse business impacts

o Ensure the best possible levels of availability and service quality

o Improve staff utilization and efficiency

o Protect user and customer satisfaction

2.3 Definition

What is an Incident?

An incident is any event that:

o Is not part of the standard operation

o Is a deviation away from normal working practice

o Causes (or may cause) an interruption in service

o Causes (or may cause) a reduction in service quality

NOTE: An Incident is NOT the same thing as a Problem!



24/91

2.4 Scope

The scope of Incident Management covers:

o Applications Hardware

o Service Requestso Service Availability

o Deviations from normal service (Service Levels)

It is important to remember that Incident Management handles regularIncidents, Service Requests and Major Incidents.

2.5 Benefits

The benefits of Incident Management are:

o Reduce the impact of Incidents by focusing appropriate

resources, in a timely mannero Proactive identification of enhancements or repeat occurrences

o Improve the monitoring of performance against known Service

Levelso Ensuring that Incident Records have the correct details within

them, both at the start of the Incident and throughout its life.o Ensuring that Incident Records are correctly labeled at closure

time to enable proactive trend analysis of Incidents.

o Improve user and business satisfaction levelso Provide assurance for the business and IT Service Management

that the right people and things are executed at the right time.

2.6 Process

The Incident Management process involves the following activities:

o Detection and recording

o Classification and initial support

o Investigation, diagnosis and escalation (if required)o Ongoing Incident ownership, monitoring, tracking and

communicationo Incident Closure



25/91

2.7 Incident Classification

Incidents are classified at three stages:

1. Initially > to determine the type of Incident2. Throughout the life of an Incident > to track changes inclassification3. At Incident Closure > to ensure the right classification for analysisand reporting.

Examples of Incident Classifications include:

o Fault

o Operating Systemo Error Message

o Bug Low Performance

o Hardware

o Server

o Configuration

o Set-up error

2.8 Escalation

Incident escalation is critical to ensure that Incidents are managedthroughout their overall duration. The timeliness of who attends to anIncident, when and what is done to close an Incident is assisted byIncident escalations. Typical examples of escalations include:

o Transferring an Incident from second line support to third line

supporto Making a higher level of IT Service Management aware of the

Incident's status (or existence)o Engaging with external (third party) support to provide

assistance with Incident Management activities.

Incident Management also concerns itself with the management of aspecial category of Incident - known as Major Incidents. These areIncidents that have a very high impact (real or potential) on theorganization.



26/91

Typically Organizations have a specially defined set of escalationprocedures for Major Incidents where senior business and IT ServiceManagement are more frequently appraised of status, progress andclosure information.

2.9 Incident Manager Responsibility

The Incident Manager is responsible for:

o The overall process efficiency and effectiveness

o The general operation of the function - Managing the provision of

the right skilled resources (for example across first and secondline support teams)

o Identifying, monitoring and making important decisions against

metricso Assuring the availability of the Incident Management function

o Producing management information reports - Managing Major

Incidents

2.10 Tools

For Incident Management the use of an integrated IT Service Tool isparamount. Incidents are usually logged by the Service Desk andcategorized before handing off electronically to an IT support function

such as Desktop support. Here, Incidents are received and initialsupport, diagnosis and escalation can occur.

Note that (typically) one overarching primary tool is used to store real-time data and information about the status, detail and progress of anIncident whilst other (local) tools are often used to identify anddiagnose the Incident.

Each support area usually has several tools that are application,Infrastructure or Service specific. These supporting tools are also vitalfor the Incident Management process. They enable the rapid diagnosis

of an Incident often in a very complex environment.

Smart organizations have provided the Service Desk with certain'views' of the IT environment so that they may correctly record,classify and begin to diagnose Incidents at the point of receipt (fromusers). This saves vital minutes and leads to a better hand-off to thesupport function, if needed.



27/91

2.11 Metrics

The accurate capture, storage, manipulation and presentation ofIncident Management metrics is vital to enable IT Service Managementto make effective decisions. These decisions can be at three levels:

o On an individual Incident basis (to provide an accurate account

of the Incident's overall timeline; who did what, when)o On a Incident Group basis (to determine specific trends, say a

particular router is failing between 0900 and 1000 every Mondaymorning)

o On an overall functional level (to determine the number of

business impacts, by Incident category, per week)

Typical examples of Incident Management Metrics include:

o Number of Incidents received, by category

o Average time to close an Incident (from receipt)

o Volumes of Incidents handled, by team or an individual

o Number of Incidents not closed successfully within agreed

Service Levels and the reason(s) whyo Number of Incidents closed by the Service Desk (where usually

staff costs are lower per head than a second and third line

colleague)o Average cost of closing an Incident

o Average cost of impact of an Incident to the business It is very

important to stress that metrics and the resulting reports mustbe viewed holistically and from a number of angles beforemanagement decisions are taken. Positively impacting onemetric (e.g. Average time to close) can negatively impactanother (e.g. Number of repeat Incidents).



28/91



29/91

2.12 Challenges

The Incident Management function face a number of day to daychallenges:

o Communication: many different IT and business users may be

involved at different stages over a prolonged period of time.o Bypassing the Process: Sometimes users and business areas will

deliberately or unknowingly bypass the Incident ManagementProcess. It is critical that users understand how to access theService Desk to ensure that Incidents are correctly recorded andthe management process begins.

o Quality of Information: real-time information is open to people's

interpretation, sources of information vary across the life of anIncident and facts may only come to light after the Incident hasbeen closed.

o Maintaining Momentum and Ownership: avoiding support teams

taking too long to diagnose an Incident, avoiding scope creepwhereby the clock is ticking and no positive decisions are beingtaken - or - managing to maintain control and ownership whenmuch more senior people are involved in the Incident.

o Restoring Normal Service Operations: managing conflicting views

between support teams to reach a service restoration point,deciding when to restore service, say if only a partial restorationis possible; ensuring that resources are available if the Incidentruns over an extended duration.

o The Paradox of Restoring Services V's Obtaining Root Cause

Information (e.g. Temporary Log Files): Problem Management will

often require certain information is saved safely in order toinvestigate the underlying root cause of an Incident. Performingthe save (system dump) takes valuable minutes and therefore a'call' has to be made - "restore now" V's "find the true root causeonce and for all".

o Incident Information Volumes: Excellent information

management skills are required to correctly split, cut, slice anddice key data and views of this data from ALL the IncidentManagement data that is logged. The sheer volume of Incidentsin some operations makes this challenging. - Being Proactive V'sReactive: Too many incoming Incidents can lead to a reactive

culture and people feel 'burnt out' over time. If little proactivework occurs, then Incidents may recur in the Operation, fuellingfurther reactive effort and burn out. The cycle needs to bebroken to have a positive effect in the medium term.



30/91

3 Problem Management

3.1 Mission

The mission of Problem Management is to:

Minimize the adverse impact effect on the business if bothIncidents and Problems caused by errors in the IT Environmentand to proactively prevent the occurrence of Incidents,Problem and errors

3.2 Goals

The goals of Problem Management are to:

o Identify the true underlying root cause of Incidentso Present workarounds and resolutions

o Initiate improvement actions

o prevent recurrences of Incidents

o minimize the adverse impact on the business

o ensure that the best levels of availability and service quality are

maintained

3.3 Definition

The definition of a Problem is:

The UNKNOWN underlying cause of one OR MORE Incidents

A Problem will become a Known Error when:

o The root cause is known

o A work-around or resolution has been identified

NOTE:

A workaround is also generally referred to as a "circumvention" or"temporary fix". Root Cause is also referred to as the "underlying rootcause".

It is important to commit to memory the definitions and cleardistinctions between: An Incident, A Problem and a Known Error. Thesedefinitions must be strictly adhered to.



31/91

3.4 Process

The Problem Management Process consists of the following activities:

Problem Control:

o Identificationo Classification

o Assign Records

o Investigation and Diagnosis

Establish Known Error Control:

o Error identification and recording

o Error Assessment

o Recording the error / resolution

o

Error Closure

3.5 Benefits

There are several key benefits of Problem Management:

o Proactive prioritization of which Problems should be eliminated

first (and second...)o Understanding of where the Organizations 'pain' areas are.

o An holistic view of where ALL of the Organizations problems are

up to in terms of status.o The provision of permanent resolutions to Problems to help drive

IT Service Quality and business satisfactiono Improve the opportunities for Organizational learning and pro-

activeness.o Support the Incident Management and Service Desk functions by

providing constructive feedback on the quality of their work.



32/91

3.6 Relationship between Incident, Problem, Known Errors and Changes

Four Key Terms

It is important to understand clearly the relationship between thesefour terms:

o Incidento Problem,

o Known Error

o RFC

First, the easy and straightforward scenario: An Incident is aninterruption to IT Service. Some Incidents occur and are closed with nofurther action required. Some Incidents require a change to be raisedin order to close them. Therefore Incident Management will raise arequest for change (RFC) to the Change Management function.

Now, the more complex scenario: Following the occurrence of one ormore Incidents, a Problem Manager may choose (or be asked) to raisea Problem Record. Remember - a Problem is the unknown cause of oneor more Incidents. Once investigated and diagnosed, the ProblemManager may then raise a known error record. (Incidentally, a knownerror record could actually remain open indefinitely within a knownerror database if the IT Service Organization deems it not viable, sayfor reasons of cost, to raise a RFC and eliminate the root cause of theProblem).

However, more commonly the IT Service Organization (or the business)will deem it important enough so they can raise a request for change(RFC) to ensure that a suitable and FULL resolution to the problem isimplemented into production.

After the implementation of a successful change, both the Known Error record

and the Problem record can be closed. But what happens to the originalIncident record?

Two scenarios are likely:

Given the nature of Incident Management is it unlikely that the Incidentrecord will still be open after an extended time period. Remember thatIncident records may be closed by Incident Management when theIncident is closed I.E. Normal IT Service has resumed. So, If asatisfactory workaround has been deployed, and normal service isresumed, then the Incident record can be closed. This usually happensquite quickly in most organizations.



33/91

If the original Incident has no suitable workaround then the IncidentManagement function will pass the Incident details over to ProblemManagement as soon as deemed necessary. Problem Management willthen work as described above, but the entire RFC cycle (described inChange) will take place with great haste to ultimately reach a pointwhere a resolution can be deployed into production to restore normal

service.

At this point the Incident record can be closed (because normal servicehas resumed) and both the Problem and Known Error Records may beclosed too.

3.7 Reactive Problem Management

Reactive Problem Management has to effectively deal with newincoming Incidents. Problem Management will review Incident details,

configuration details and any defined workarounds. ProblemManagement will then follow the Process steps of Problem Control andError Control to effectively determine the root cause of the Problemand highlight a known error.

Problem Management can then:

o Recommend improved and more effective workarounds to

Incident Management (in case of recurrence)o Raise Requests for Change (RFC's)

o Offer Service Improvement recommendations to the Service

Desk, Incident Management and Configuration Management.(Note: Recommendations are not limited to these IT ServiceManagement functions - but more commonly occur

3.8 Proactive Problem Management

Proactive Problem Management has three elements:

o Trend Analysis: identifying faults and general problem areas that

need to be tackled.o Targeting Preventative Support Action: by calculating the

ongoing cost of Incidents - the so called 'pain factor' - whichleads to proactive action.

o Providing relevant and targeted information to other IT Service

Management functions, such as IT Service Level Management.



34/91

3.9 Common Techniques

There are several commonly applied Problem Management techniquesthat have been used in quality circles for many years:

o Kepner Tregoe

o Ishikawa Diagrams

o IS / IS NOTo Force Field Diagrams

3.10 Major Problem Reviews

Once a major Problem has been resolved, Problem Management canfacilitate a Major Problem Review. All the staff involved in theresolution of the Problem should attend.

Key agenda items include:

o What actually happened?

o What was the cost and impact to both the business and the IT

Organization?o What was done right?

o What was done wrong?

o What can be improved next time?

o How can this problem be prevented from happening again?

o Review actions, agreed owners and target dates for next steps

3.11 Tools

Problem Management will dramatically benefit from the use of anintegrated toolset. Incident records should be easily accessible andcapable of quickly creating a Problem Management Record using coredata from the Incident record. From here any additional details addedto the Problem Record will, in turn, be capable of transferring into aChange Record.

As time passes the original core details will be added too and utilized

across many ITIL Processes. This is the power of using an integratedtoolset.

Even more powerful is when the toolset is configured in such a waythat "time" is deliberately compared with the current status of theProblem - highlighting, for example, when a breach of an SLA is due inso many hours.



35/91

The toolset should be configured to assist all teams in the execution oftheir duties.

3.12 Metrics

Key metrics for Problem Management include:

o Number of open Problems and their status

o Number of Problems closed and the elapsed time until closure

o Number of Problems that were resolved within and outside of the

agreed Service timeso Number of Problems, by category, to help drive trending

information

Additionally, Management will want to know where the 'pain' iscontinually coming from and how much impact/cost it is causing thebusiness. These Problems should receive the highest attention and beeliminated from the environment.

3.13 Challenges

The Problem Manager will face a series of challenges on a day to daybasis including:

o Managing the incoming volume of Problem Records V's

Progressing existing (open) Problem Records.o Ensuring that 'what matters most' is today's focus requires a

high degree of regular prioritisation. It is useful to have criteriaestablished and agreed up front in order to do this withoutconstantly seeking higher Management's approval.

o Collaborating with multiple groups, sometimes across different

geographies and companies (third parties), means ProblemManagement need to have excellent communication skills.

o Whilst all of this is happening, the Problem Manager will need to

ensure that regular daily, weekly and monthly reports areproduced for IT Service Management.



36/91

4 Change Management

4.1 Mission

The mission of Change Management is to:

Ensure that standardized methods and procedures are usedfor the efficient and effective handling of all changes, so thatthe impact of any Incidents on IT Service can be minimized

Remember that timeliness is key.

Most definitions of Change Management also include the word,"Prompt" to reflect this.

4.2 Goals

The goals of Change Management are to:

o Ensure the efficient and PROMPT handling of changes

o Apply standard change procedures

o Minimize the impact of any Incidents

o Improve the quality and availability of IT Service.

o In addition, Change Management protects the current IT Service

delivered to the business by ensuring that formal steps must betaken in order to implement new changes. If changes were not

formally handled, then poor quality or ill thought throughchanges could be implemented and have a negative impact on ITService, say by causing additional Incidents



37/91

4.3 Why Change Management?

Changes to an IT environment, whether it be to a Server or an ITApplication, can either come along:

Reactively - for example, if an Incident occurs.

Proactively - for example, as part of a Service Improvement Initiativeor new Project. Therefore Change Management is a critical andabsolutely necessary part of the IT Service Organization. ChangeManagement provides a structured, controlled and authorized way forchanges to enter the production environment.

Change Management must:

o Ensure that ALL changes are considered and handled

appropriatelyo Facilitate the prompt handling of Changes

o Maintain an overarching view of the status of all Changes.o Maintain the balance between allowing changes to enter

production and NOT allowing poor quality or ill timed changes toenter production. Change Management is the key guardian ofService Quality. This is a difficult and high profile role with the ITService Organization. The Change Manager has to balance theimpact, cost, benefits and risk or either approving OR notapproving the Change

4.4 Benefits

There are many benefits of Change Management:

o Protecting IT Service from the negative impacts of poorly

designed/built or tested changes.o Ensuring that the change is scheduled correctly to avoid conflicts

with important business or IT events.o Improved productivity of business and IT people since there are

less Incidentso Improved overall ability to handle multiple changes in the correct

sequence, allowing greater volumes of change to enterproduction - and therefore provide the business benefit theywere intended to deliver.

o Ability to temporarily 'freeze' (or lock-out) all Changes to provide

total protection for IT Service. This usually occurs temporarilywhen the business has a unusually high volume of activity toperform, say a retailer over the last two weeks in December. Itcan also occur for one off events, say during the first two days of



38/91

the business beginning to service a massive new customercontract.



39/91

Change Management is sometimes (incorrectly) criticized for 'slowingdown' activities leading to the implementation of new changes.

Such criticisms are usually from people who do not understand andappreciate the Change Management function. In modernOrganizations, Change Management does not slow down theabsorption of Change, it provides the "gentle brakes" to allow you to

slow down around corners and then rapidly accelerate.

What would happen if there was NO Change Management?

4.5 Change Categories

There are several Change Categories that are important to know:

Categorizing Changes correctly into Minor, Regular, Significant andEmergency.

Each Category will determine how in-depth and timely the overallassessment and approval stages are.

Ironically Emergency Changes are assessed by fewer people in lesstime - but often present the most risk to IT Service.Minor Changes will be reviewed and approved by the Change Managerand typically do not require the approval of the formal CAB (althoughsome members may be called on for their opinion).Regular Changes will be reviewed in a formal CAB

Significant Changes often require an additional level of approval bySenior IT and Business Management.

Often the term "Routine" change is also used. These are special pre-approved types of changes that present very low risk and potentialimpact. Typically these are logged and scheduled on the ChangeManagement tool - but only require local area (e.g. Telecoms)approval.



40/91

4.6 Key Roles

Change Manager

The Change Manager is responsible for:

o Day to day process management.

o Receiving, logging, prioritising and handling Requests for Change

(RFC's)o Chairing CAB Meetings.

o Chairing CAB/EC Meetings.

o Assessing the impact, cost, benefit and risk of proposed

Changes.o Authorising acceptable changes.

o Not approving unacceptable changes.

o Maintaining the Forward Schedule of Changes (FSC). - Publishing

the Projected Service Availability (PSA).o Ongoing communications with teams who are designing,

building, testing and physically implementing changes.o Post implementation review of changes.

o Initiating and acting on Improvement opportunities.

o Production of daily, weekly and monthly management

information reports.o Overall efficiency and effectiveness of the Change Process

Change Advisory Board

The Change Advisory board is a critical part of the Change Process. TheCAB is made up of a broad range of IT and business representatives, allof which represent a core part of the either the IT Service Organizationor the business.

The role of the CAB is to review, understand, assess and ultimatelyapprove or not approve each Change.

Now some changes are so small, low impact and well rehearsed that

they have special approval from the Change Manager NOT to have tobe reviewed by the CAB. Such Changes often include minorConfiguration changes to Infrastructure or when small pieces of newfunctionality, that have been tested, are 'switched on'.

However, these Changes are NOT exempt from the ChangeManagement Process (they will still be raised and approved within the



41/91

controls and visibility of the Change Team) they just do not require themore detailed scrutiny of the CAB.

It makes practical sense to not review every change otherwise theProcess could be perceived to be cumbersome and 'slow' down theprogression of Change into production.

For non routine Changes, the CAB will:

o Formally meet to review the Change

o Assess the change against certain criteria, appropriate to the

organization and the complexity and risk of the changeo Advise the Change Manager on which changes should be

approved or not approved, and the reasons whyo Advise on the actual scheduling and correct timing for the

change to be implemented, avoiding negative impacts to ITService.

CAB Attendees include :

o Interested Business area representatives.

o Incident Management.

o Problem Management.

o Configuration Management

o IT Programme Managers.

o Technical Support Representatives.

o Suppliers, Maintainers and Developers.

o Experts and Technical Consultants.

o IT Service Managers.o The Change Manager and Change team members.

The attendees are not limited to the above list, and will differaccording to the needs of each Organization. Some Organizationschoose to only invite certain CAB members when certain types ofchanges are scheduled for review. This helps to maintain the efficiencyof the Change Process



42/91

CAB Emergency Committee

The CAB Emergency Committee exists to provide an emergencyservice to review, assess and ultimately approve or not approve anemergency change.

Oftentimes, the need for Change approval will not coincide or cannotwait for the next standard CAB meeting. This occurs most when either

action is required to protect or restore IT Service (say, as the results ofan Incident) or when some key component of a project has beenincorrectly dealt with (say, a critical data file needs updating in real-time to ensure that another planned change will take placesuccessfully).

The CAB/EC is made up of a known sub-set of regular CAB members.The CAB/EC provides essential emergency assistance to the ChangeManager to help deal with specific urgent, late or previouslyunrecognised Change requests. In such cases, it is typical for theCAB/EC meeting to take place via a conference call. Such conference

calls can happen at any time including out of office hours and atweekends.

The 'agenda' is the same as a standard CAB, however the risk factor(because not all the CAB are present - or there is little time to engagewith others) is typically higher.

Essentially, the CAB/EC facilitates a "fast tracking" of the normalChange Process to try to facilitate business need whilst protecting ITService. A difficult balance!

4.7 Process

Process Lifecycle

The Change Process consists of the following core lifecycle stages:

o Logging and Filtering

o Prioritisation and Categorisation

o Impact and Resource Assessment

o Authorization

o

Schedulingo Change Design / Build

o Change Test

o Change Implementation

o Post Change Review

o Close



43/91

Important Activities

There are several important activities that help to underpin thesuccessful operation of Change Management:

o Logging and Filtering of Requests to prevent duplicate or poor

quality change requests entering the Change Management

Processo Applying a 'Priority' to each Change. This will drive the speed of

assessment and also the level of scrutiny that's applied by theCAB (or CAB/EC).

o Applying the Change Category (Minor, Standard, Significant,

Emergency)o CAB members assess the information provided on a Change

Record by the Change Initiator (sometimes the same as theperson who 'raised' the change). The assessment includes areview of impact, risk, resources and the required timing(schedule) of the Change. - CAB members will either approve theChange or not approve the change (stating the reasons why).

o Approved Changes are passed to the Change designer/builder

along with official notification of the approval and the specifiedimplementation schedule.

o The Change builder must also devise back-out plans. It's

important for the CAB to see these and appreciate that in theevent that something untoward happens, the Change can bebacked out quickly and effectively with no impact to IT Service.

o Typically, an independent test team (or test manager) will be

appointed for each specific Change. The goal is for each Change

to be fully tested before it enters production to avoid anynegative impact to IT Service



44/91

4.8 Tools

Change Management requires the use of an integrated toolset to store,update, check and retrieve important information about each Change.

The Change Management tool should be integrated and offer workflowcapabilities from: Incident, Problem and Configuration Management; aswell as provide visibility for Change requestors, designers, builders andtesters.

The Change Management tool should be fully integrated with theConfiguration Management function, particularly with respect to theidentification, linking and real-time updates of the status ofConfiguration Items.

The Change Management tool should also provide reporting

functionality to enable Change to provide Management with historicand 'look ahead' reports. Such reports will be utilized within CAB andCAB/EC meetings. It is also important that 'one version of the truth' ismaintained and protected at all times.

Where multiple tools (or views of data) exist - Change Managementmust determine the sole source of Change information. Importantdecisions must only be made from one reference source - otherwiseincorrect decisions will be taken and this may impact IT Service.

4.9 Metrics

Key metrics for Change Management include:

o Number of Changes, by priority and category, and then status.

o Number of Changes rejected by CAB, and the reason(s).

o Number of Changes approved and awaiting Implementation

o Number of Changes currently scheduled.

o Number of Emergency Changes, along with the reason why it's

an emergency - so the Change Manager can recommend (or

insist) on this type of Change becoming a regular Change nexttime. The goal is to minimize the number of Emergency Changesbecause these are considered higher risk.

o Number of successful V's unsuccessful (failed) Changes, by

category, by requesting area. This will help to identify wherepoor quality Changes are coming from and lead torecommendations for overall improvement



45/91

4.10 Challenges

The Change Manager will face a number of day to day challenges:

o Lack of awareness and understand of the Change Process by

the IT Organization.o Lack of support from the CAB and/or CAB/EC - Managing the

volume of incoming Changes to avoid bottlenecks in thereceipt and assessment of Changes.

o Lack of control over the volume of emergency Changes and

the level of influence Change Management have over thisvolume in the future.

o Lack of an accurate Configuration Management Database

(CMDB) to underpin the Change Process.o Lack of knowledge and ownership of key individuals when

assessing any Change, for example not fully appreciating theknock-on impacts of performing the change on other IT

Services.o Ensuring that the Change function is perceived as adding

value V's 'slowing down' the absorption rate of new Changesto support IT Service objectives and business requirements.



46/91

5 Configuration Management

5.1 Mission

The mission of Configuration Management is to:

Provide a logical model of the IT Infrastructure by identifying,controlling, maintaining and verifying the version of allConfiguration Items in existence

5.2 Goals

The goals of Configuration Management are:

o Account for the existence and status of IT assets and

Configurations.o Control and maintain the status of IT assets.

o Support all the other IT Service Management Processes.

(especially Incident, Problem, Change and ReleaseManagement).

o To support the adherence to legal, licensing and contractual

obligations. *What's where? What's it doing? Is it 'legal'?

5.3 Definitions

Important Definitions:

o Configuration: anything that we need to record and control. A

Configuration can be broken down into a number ofConfiguration Items (CI's)

o Configuration Item (CI): any individual Infrastructure component

or an item (for example an Incident Record) related to theInfrastructure within a Configuration.

o A CI can vary considerably in type, size and complexity; ranging

from a whole system down to a specific component on a circuitboard.

o A CI can also be broken down into any number of Component

CI's.o The hierarchy, different levels and details at each level at which

CI's are defined and grouped varies between IT ServiceOrganizations.



47/91

o It is Configuration Management's role to identify and standardize

on a hierarchy that is suitable for any given Organization.

5.4 Scope

The scope of Configuration Management is very important and may beconsidered in two dimensions:

Across IT Services and Infrastructure - Down into CI's and differentlevels of Hierarchy.

For example, Configuration Management will need to determine thescope of what CI's will be identified and managed across the huge

range of it's IT Services and Infrastructure. Will all third partyapplications be included? Will the recently acquired third party datacentre be covered and included in scope?

Secondly, the CI's levels will need to be defined and managed down foreach CI item.

For example, take a typical PC. Should the CI level be:

o PC

o Keyboard

Mouse

Screeno CPU.

Should Configuration Management also identify and control the CPU'sCI's:

o CPU

o Circuit Board

Firmware

Chipseto Interfaces

Fan

Clearly "Scope" is two dimensional and the scope selected needs tobest service the needs of the IT Service Organization, to in turn, bestservice the business.



48/91

5.5 Benefits

The benefits of Configuration Management:

o Provides accurate and timely information on CI's to support other

IT Service Management Processes.o Facilitates the adherence to legal and contractual requirements

such as Software Licenses.o Facilitates the adherence to cost controls and budgets, especially

useful for knowing how many of each item is maintained within,say a maintenance contract. - Improves the visibility of any CI'scurrent status e.g. A certain Server currently has an Incidentlogged against it, so Change Management can easily see this anddetermine whether to go ahead and approve a Change or not.

o Improves the overall level of consistency and standardization

across a multiple CI type. For example: Are all PC's currentlyrunning the same level of Operating System?

o Supports Security Management (note: Not a Service Support or

Service Delivery Discipline) by highlighting any "unknown" CI'sfor example an "unknown" Service is connected to the corenetwork. What is it? Who owns it? How is it configured?

o Facilitates impact analysis for Incident and Problem

Management.o Provides confidence for IT Service Senior Management that

everything is truly "known", is "under control" and can bereferenced in a structured way.



49/91

5.6 Process

The Configuration Management Process contains the following stages:

o Planning: The Configuration Management Plan should include:

scope and objectives, policies and standards, roles andresponsibilities, CI naming conventions and the design of the

Configuration Management Database (CMDB).o Identification: The selection, identification and labeling of all

required Configuration Items (CI's). This covers variousinformation on CI's including: names, owners, relationships,versions, status and identifiers. Naming conventions must alsobe established.

o Control: This stage ensures that no CI is added, modified or

replaced without the appropriate controls. All CI's will be underChange Management control. This stage also providesManagement assurance that only authorized CI's are recorded.

o Status Accounting: Reports are regularly produced containing

current and historical data on all CI's. It enables changes andtracking of CI's. Accounting occurs over the lifecycle of a CI -from order, receipt and implementation - through to ongoingstatus and finally withdrawal and disposal. This stage is used toestablish baselines.

o Verification and Audit: Checks to ensure that the CMDB reflects

the physical configuration and vice-versa. For example: A checkto ensure that the live environment is correct before a majorRelease. Automated audit tools should be used to assist theConfiguration Team. Also included is the formal verifying of

Release and Configuration documentation before Changes aremade to the live production environment.

5.7 Relationships with other Processes

Configuration Management is closely linked with other IT ServiceSupport and Service Delivery Processes:

o Incident.

o Problem.

o Known Error.o Request For Change

o Change Authorized

o Change tested

o Implemented

o Released



50/91

5.8 Key Terms

CMDB

The Configuration Management Database (CMDB) is designed to hold

details of CI's, their attributes and their relationships. Anotherimportant purpose of the CMDB is that is enables other IT ServiceProcesses to be able to use the information to support other processesat key stages. For example: - Incident Management will ensure thatany CI currently out of normal service operation, is flagged as such inthe CMDB. This in turn, allows Change Management to makeappropriate decisions when assessing requested Changes. The CMDBis a complex relational database that enables real-time multiple accessto many CI's. Therefore the structure, levels, organization and overall"correctness" of the CMDB is a critical underpinning feature of ITService Management.

Definitive Software Library

The Definitive Software Library is a physical library which holdsdefinitive and authorized versions of all Software. Any access toSoftware in the DSL is strictly controlled by Change Management andRelease Management. It is the 'one version of the truth', in terms oftrusted Software versions, as utilized in the live productionenvironment

Baseline

Baseline - A set of CI's that have been frozen at a specified point intime. - A snapshot of the configuration acting as a key marker point tofacilitate either progression of a Change or Release - or a reversal of aChange or Release. - The snapshot contains all structural and CI detailsat any particular moment in time. - The snapshot can act as a markerfor Change or Release reversals should something go wrong. Thereforeit is an important record of a particular 'moment in time'.Level of Control

Level of Control - The Configuration Process aims to target maximumcontrol with the minimum amount of records in the CMDB. This'sweetspot' needs to be carefully thought through and planned. - SomeCI's will deliberately have more details than others. Not all CI's arerecorded to the same level. - What's appropriate to the Organization iswhat matters most. - Typically, Configuration Managers will startplanning their CI levels and CMDB structure by looking at critical IT



51/91

Services and understanding what's important to record within relevantCI's.



52/91

5.9 Configuration Manager's Responsibilities

The Configuration Manager is responsible for:

o The overall efficiency and effectiveness of the Process.

o The maintenance of the function, including the provision ofsuitably skilled and experienced staff.

o The production of reports to support the goals of Configuration

Management.o The enhancements to the Process to provide quality and

accurate information within the CMDB to support other Processessuch as Incident, Problem, Change and Release Management.

o The design, configuration and upkeep of the CMDB. This is

challenging since the CMDB will need to be kept up to date withregular updates from all aspects of the IT Infrastructure andtargeted IT assets.

5.10 Tools

There are three important types of tool to consider for ConfigurationManagement:

The CMDB:

This is the heart of any Configuration Management Process. The CMDBis the central storage area for the definition and status of all relevantCI's. The CMDB is a complex relational database that stores, updates,adds, removes and provides status reports on the CI's and theirrelationships at many different moments in time. The CMDB should bekept up to date at all times. However, in reality some aspects of theCMDB will only be as accurate as the last known update. It is oftenimpractical to update all of the CMDB in real-time for every possible'event' that occurs. See "agents" for an explanation.

The Integrated Toolset:

Again, with Configuration Management, the existence of an integratedIT Service Toolset is important and will help to ensure that informationis shared in the right place at the right time. For example: details fromIncident records should automatically update the status of relevantCI's. Similarly for Change: Any CI's currently having a Change loggedagainst them should be marked as such within the CMDB. Theintegrated toolset will know this and can provide real-time, accurate



53/91

information as to the status of any CI. So long as the toolset and theCMDB have been purposely configured to provide this view.



54/91

IT Asset "agents":

Each Infrastructure and Software asset in the IT Environment will needto be registered and made known to the CMDB. Typically, assets run"agents" which are special pieces of software that are designed to talkto the CMDB at pre-defined intervals, or when certain events aretriggered or closed. Agents can be stored locally, say on a router, and

configured on that particular device. Agents can also be found withinthe CMDB itself and can go out and seek (auto discover) assets. Thirdparty vendors often provide intelligent agent software for thesedevices. To avoid 'traffic floods' or unnecessary updates, some assetsare configured for only major events whilst others are configured to tellthe CMDB everything that happens. Again, the configuration of agentsdepends on what information the Configuration Manager requireswithin the CMDB. Sometimes, the CMDB will run at a pre-defined levelof accuracy and only when necessary (say, before a major Release) willthe Configuration Manager execute special routines to obtain asnapshot (Baseline) of absolutely everything.

5.11 Metrics

The accurate capture, storage, manipulation and presentation ofConfiguration Management metrics is vital to enable IT ServiceManagement to make effective decisions. The CMDB in conjunctionwith "agents" and the integrated toolset can achieve this.

Typical Metrics include:

o Lists of CI's, by category (used for Audit reports).

o Status of a particular group of CI's.

o The status of one CI (say, that has an Incident recorded against

it).o The time and date stamp of when a CI was last made known to

the CMDB.o List of all Software installed (to match against the license

agreement).o Snapshots of ALL CI's (prior to a major release - in case things go

wrong).



55/91



56/91

5.12 Challenges

The Configuration Management function face a number of day to daychallenges:

o Designing the CMDB.

Selecting the correct 'level' at which to record, process and manipulateCI's is a challenge. If the level is too low (detailed) then there may betoo much data for the IT Service Organization to handle and effectivelyutilize. Too much data or an over-ambitious level of detail can presentother Processes with a cumbersome quantity of data to handle. Toolittle data and the Processes do not receive useful information toleverage the power of the CMDB.

o Maintaining the CMDB.

Once the level of CI's is agreed and configured into the CMDB andagents, the challenge then becomes ensuring that the agents work asagreed and actually do populate the CMDB with the right informationat the right time. Agents are software components and these failoccasionally too.

o Leaving the CMDB with knowledge gaps that need to be regularly

identified and plugged.

Just think about the sheer size and complexity of this task in your ITOrganization. How many PC's do you have? How many Servers,

Printers, Software Packages, IT Services, Networks, Databases? Now,multiply that total number by, say, three because it's assumed thatthere are three related (lower level e.g. Keyboard) CI's for each knownasset. You should have a pretty big number in your head.

o Ensuring assets can 'talk' to the CMDB.

The CMDB selected will typically be bought from a major Vendor. MostCMDB's are already fully integrated with the IT Service toolset.However, challenges can occur when you consider how to obtaininformation from another Vendors asset that uses a different way of

communicating, say a different agent. Thankfully communicationstandards usually mean that this can easily be overcome - but thereare exceptions. Sometimes, separate local CMDB's are needed tomanage certain "islands" of CI's, which then feed the master CMDB.When purchasing new assets, the IT Service Organization needs toensure that their agents are compatible with the selected CMDB - bothnow and in the future.



57/91

o Lack of tools or tooling expertise.

All tools are not equal. Sometimes, particularly for older Assets (say,older Network equipment) agents will not readily be available.

Decisions will need to be made about how the information is providedto the CMDB. Sometimes intelligent scripts are written and executedfrom Servers that 'go out' and interrogate the legacy equipment.Maintaining a CMDB requires a competent IT Service Organization.Specific skills and experience sets are valuable for the accuratemaintenance and ongoing support of the CMDB.



58/91

6. Release Management

6.1 Context

It is important to understand the context of Release Management.

Although the Release Management function is an IT Service Function -it does have a great deal of day to day involvement with the ITDevelopment and Project Management part of the IT Organization.

Although staff in these areas will design, build, configure, test andimplement systems and Infrastructures; it is Release Management'sresponsibility to ensure that this is achieved in a structured manner foranything that is purposely defined as a 'Release'.

6.2 Mission

The Mission of Release Management is to:

Apply an holistic view of a Change to an IT Service and ensurethat ALL aspects of a Release (technical and non technical) areconsidered together. To ensure that releases are implementedin a safe, structured and secure way that will protect the Liveenvironment from the negative impacts of Change

6.3 Goals

The Goals of Release Management are to:

o Implement new releases.

o To oversee the rollout of software, hardware, relevant components

and documentation. - To ensure that only correct, authorized andtested versions are implemented.

o To maintain the Definitive Software Library (DSL) and the Definitive

Hardware Store (DHS).o To manage the Release Process with Change and Configuration

Management.o To ensure that only properly licensed Software is in use. This means

no unlicensed or pirate software exists. It also means that unusedlicenses are identified and any refunds are

Date post:	09-Apr-2018
Category:	Documents
Upload:	adityapankaj55
View:	217 times
Download:	0 times

Foundation Gui Dev 1

Documents