IT Service Success

FOUNDATION STUDY GUIDE

© 2006 IT Service Success

1

The Foundations of IT Service Management
IT Service Success

FOUNDATION STUDY GUIDE.............................................................................1 The Foundations of IT Service Management...................................................2 The Importance of IT Service Management.....................................................6 What is IT Service Management? ...................................................................7 Why use ITIL? .................................................................................................9 What exactly is ITIL?.....................................................................................11 Benefits of ITIL explored................................................................................13 Additional benefits of adopting ITIL:...................................................14 ITIL Processes................................................................................................15 1 Service Desk..............................................................................................15 1.1 Function........................................................................................15 1.2 Mission..........................................................................................15 1.3 Goals.............................................................................................16 1.4 Benefits.........................................................................................17 1.5 Understanding the customer / user..............................................17 1.6 Organization.................................................................................17 1.7 Staffing.........................................................................................18 1.8 Structure.......................................................................................18 1.9 Tools.............................................................................................20 1.10 Metrics........................................................................................21 1.11 Challenges..................................................................................22 2 Incident Management................................................................................23 2.1 Mission..........................................................................................23 2.2 Goals.............................................................................................23 2.3 Definition......................................................................................23 2.4 Scope............................................................................................24 2.5 Benefits.........................................................................................24 2.6 Process.........................................................................................24 2.7 Incident Classification ..................................................................25 2.8 Escalation.....................................................................................25 2.9 Incident Manager Responsibility...................................................26 2.10 Tools...........................................................................................26 2.11 Metrics........................................................................................27 2.12 Challenges..................................................................................29 3 Problem Management................................................................................30 3.1 Mission..........................................................................................30 3.2 Goals.............................................................................................30 3.3 Definition......................................................................................30

© 2006 IT Service Success

2

3.4 Process.........................................................................................31 3.5 Benefits.........................................................................................31 3.6 Relationship between Incident, Problem, Known Errors and Changes...............................................................................................32 3.7 Reactive Problem Management....................................................33 3.8 Proactive Problem Management...................................................33 3.9 Common Techniques....................................................................34 3.10 Major Problem Reviews...............................................................34 3.11 Tools...........................................................................................34 3.12 Metrics........................................................................................35 3.13 Challenges..................................................................................35 4 Change Management.................................................................................36 4.1 Mission..........................................................................................36 4.2 Goals.............................................................................................36 4.3 Why Change Management?..........................................................37 4.4 Benefits.........................................................................................37 4.5 Change Categories........................................................................39 4.6 Key Roles......................................................................................40 4.7 Process.........................................................................................42 4.8 Tools.............................................................................................44 4.9 Metrics..........................................................................................44 4.10 Challenges..................................................................................45 5 Configuration Management........................................................................46 5.1 Mission..........................................................................................46 5.2 Goals.............................................................................................46 5.3 Definitions.....................................................................................46 5.4 Scope............................................................................................47 5.5 Benefits.........................................................................................48 5.6 Process.........................................................................................49 5.7 Relationships with other Processes...............................................49 5.8 Key Terms.....................................................................................50 5.9 Configuration Manager's Responsibilities.....................................52 5.10 Tools...........................................................................................52 5.11 Metrics........................................................................................54 5.12 Challenges..................................................................................56 6. Release Management................................................................................58 6.1 Context.........................................................................................58 6.2 Mission..........................................................................................58 6.3 Goals.............................................................................................58 6.4 Appropriateness............................................................................59 6.5 Key Terms.....................................................................................59 6.6 Relationship to Configuration Management..................................60 6.7 Scope............................................................................................61 6.8 Benefits.........................................................................................61 6.9 Process.........................................................................................62 6.10 Release Management's Responsibilities.....................................63 6.11 Integrated Plans..........................................................................63 6.12 Tools...........................................................................................64 6.13 Metrics........................................................................................64 6.14 Challenges..................................................................................64 7 Capacity Management...............................................................................66 7.1 Mission..........................................................................................66

The Mission of Capacity Management is to: .......................................66 © 2006 IT Service Success 3

“Understand the organizations operation and IT infrastructure to ensure that all current and future capacity and performance aspects of the business requirements are provided cost effectively at the right time”....................................................................................................66 Effective Capacity Management means "No Surprises!".....................66
7.2 Goals.............................................................................................66 7.3 Scope............................................................................................66 7.4 Benefits.........................................................................................67 7.5 Process.........................................................................................67 7.6 Capacity Manager's Responsibilities.............................................68 7.7 Capacity Database........................................................................68 7.8 Tools.............................................................................................69 7.9 Metrics..........................................................................................69 7.10 Challenges..................................................................................71

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

8.1 Mission..........................................................................................72 8.2 Goals.............................................................................................72 8.3 Scope............................................................................................72 8.4 Key Terms.....................................................................................73 8.5 Benefits.........................................................................................73 8.6 Techniques....................................................................................74 8.7 Process.........................................................................................76 8.8 Tools.............................................................................................77 8.9 Metrics..........................................................................................77 8.10 Challenges..................................................................................78 9 IT Service Continuity..................................................................................79 9.1 Mission..........................................................................................79 9.2 Goals............................................................................................79 9.3 Scope............................................................................................79 9.4 Benefits.........................................................................................80 9.5 Process.........................................................................................80 9.6 Metrics..........................................................................................81 9.7 Challenges....................................................................................81 10 Service Level Management......................................................................82 10.1 Mission........................................................................................82 10.2 Goals...........................................................................................82 10.3 Scope..........................................................................................83 10.4 Benefits.......................................................................................83 10.5 Process.......................................................................................84 10.6 SLA Content................................................................................84 10.7 Tools...........................................................................................85 10.8 Metrics........................................................................................85 10.9 Challenges..................................................................................85 11 Security Management..............................................................................86 11.1 Mission........................................................................................86 11.2 Scope..........................................................................................86 11.3 Benefits.......................................................................................86 11.4 Process.......................................................................................87 11.5 Relationships with other disciplines............................................87 11.6 Metrics........................................................................................88 11.7 Challenges..................................................................................88

8 Availability Management..................................................................72

© 2006 IT Service Success

4

Organizations That Promote ITIL ..................................................................89 ITSMF............................................................................................................90 THOMPSON PROMETRIC................................................................................91 Thomson Prometric is the recognized global leader in testing and assessment services, providing paper-and-pencil, Internet and computerbased testing solutions. It offers a fully integrated testing system that includes test development, test delivery and data management capabilities. .......................................................................................................................91 Since 2002, Thomson Prometric and EXIN have collaborated on the delivery of the ITIL Foundation exams in English. As a result, EXIN can improve the accessibility of EXIN's IT Service Management (ITIL) exams for more candidates worldwide, and test them in the highly secure, consistent Thomson Prometric Testing Center environment, while providing candidates with improved flexibility in choosing both the test date and location. .........91 www.prometric.com......................................................................................91

© 2006 IT Service Success

5

The Importance of IT Service Management
Over the years the reliance on IT services has never been more prevalent. As Businesses grow, the IT services they utilize and rely on become more complex, competitive. Alongside this the environments have become more regulated. IT Managers are challenged daily with the co-ordination and working in partnership with the business to continuously deliver high quality IT services. IT Management is concerned with the effective and efficient use of the four Ps :

People Processes Partners Products

With all this in mind a need has arisen for the creation of a standard set of practices to manage the IT services being delivered. As a result of this requirement the Information Technology Infrastructure Library (ITIL) was created. ITIL is widely recognized throughout the world, and may well be the most widely accepted approach to managing and delivering IT services today. 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

6

This guide will provide you information on the above topics, in non technical, easy to understand terms with the objective being that upon completion of this document you will have a good understanding of ITIL that can be used a the basis for your ITIL Foundation Learning Program.

What is IT Service Management?
IT Service Management is a top-down, business driven approach for the management of IT that intentionally addresses the strategic business value generated by the IT organization and the need to deliver a high quality IT service. IT Service Management is designed to focus on the issues that IT organizations face on a daily basis - the people, the processes and the technology issues. Whilst IT Service Management as a concept is related to ITIL it is not the same. When comparing the two, ITIL can be seen as an instance of an ITSM framework, whilst also containing a subsection specifically entitled ‘IT Service Management’. IT Service Management within ITIL is the combination of the Service Support and Service Delivery volumes. These are explained in more

© 2006 IT Service Success

7

detail later in the document.

© 2006 IT Service Success

8

Why use ITIL?
ITIL is popular because of the proven best practices that it offers. The demand for information about ITIL continues to grow. Among other reasons for investigating ITIL recommendations, one common motivation is to learn about knowledge and best practices necessary for achieving compliance with Sarbanes-Oxley and other IT governance requirements. Another thing to consider is that ITIL is the only consistent and comprehensive documentation of best practice for IT Service Management. Most IT-departments are event driven and operate in a reactive environment, with day to day activity spent resolving issues, i.e. service unavailable. Not only are these situations frustrating, but they are also costly. The choice to adopt and implement is in the majority based on the fact that the organization is able to understand better the Total Cost of Ownership (TCO) and the actual activities undertaken within the IT-department. ITIL provides a proven method for planning, processes, roles and the how 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 the business demands & are becoming too expensive The customers perceive the current service(s) being delivered as poor quality & unreliable Potential for audits to raise concerns regarding reduced accountability & inability to be benchmarked. Major incidents are impacting revenue and service restoration is becoming timely and expensive. To support strategic business objectives. To support and initiate a restructure, consolidation & corporate governance To improve service based on proven Industry Best Practice & standards Finally to improve service to customers and to stop re-inventing the wheel

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

© 2006 IT Service Success

9

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

© 2006 IT Service Success

10

What exactly is ITIL?
Originally produced in the late 80’s – early 90’s as a set of more than 40 volumes, however, thankfully, this has now been reduced to a set of six books that describe IT Service Management Best Practice. ITIL has now become the de-facto standard in Service Management and as it focuses on the best practice it can be tailored according to need. Over the years ITIL has now become relevant to all organizations, whether they 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 IT services, whilst faced with the challenges of budgets, skill shortages, complexity of systems, rapid change and growth, current and future user / customers requirements and the ever growing challenge of increasing 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 also offer guidance on the accommodation and environmental facilities needed to support IT. √ The books are the only comprehensive, publicly available guidance for IT service management.

The collections of volumes are produced by the OGC – Office of Government Commerce (previously known as CCTA). √ The books are best practice guidelines describing the ‘what’ rather than the ‘how’.

Whilst the UK Government created ITIL via the CCTA, it is quickly being adopted throughout the world as the standard for best practice in the delivery of IT Services. The main focus of ITIL is the IT Service Management (ITSM)

© 2006 IT Service Success

11

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

These two areas are made up of 10 disciplines

© 2006 IT Service Success

12

Benefits of ITIL explored
Fact : IT is what drives businesses today! The profitability and shareholder loyalty of an organization is dependent on the high availability, dependability, security and performance of IT services. This has made the maturity or immaturity of IT management highly visible. By improving the IT processes, the organization can begin to: o o o o o o o o o o o o o Improve project deliverables and the time to deliver; Improve resource utilization; Reduce the need for rework; Improve availability, reliability and security of mission critical IT services; Be more competitive in the market place; Justify to the business the cost of service quality; Provide services that meet business, customer and user demands Eliminate redundant work Integrate central processes Document and communicate roles and responsibilities in service provision Learn from previous experience Measure the services offered and the customer satisfaction linked to these services Provide demonstrable performance indicators

Some intangible Benefits of ITIL: During the past decade, the reshaping of business functions as processes have become a well know and reputable strategy for reducing costs, reducing cycle times, and improving quality and customer satisfaction. There is a growing appreciation that IT is a key driver of business process improvement. This has led to a predictable change in the expectations for the IS organization to follow the process changes occurring within the finance, sales, marketing and manufacturing arenas. In some cases, this has led to the formation of such organizational

© 2006 IT Service Success

13

structures as relationship managers, steering committees and user councils to improve the alignment of business and IT planning. A further consequence of the change has been to look at functionally disconnected IT activities as linked sets that share common information 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 customers o Better accessibility to services for users through single point of contact o 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-making o Reduced impact on the company’s business activities o Better management and control over the IT system’s infrastructure o More effective and efficient usage of resources related to service provision and subsequent cost reduction potential o 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 enquiries o Reduced numbers of incidents o Discovery and implementation of permanent solutions Reduced expense in developing processes, procedures and instructions o 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

© 2006 IT Service Success

14

o Improve the communication between the IT departments and its customers o 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 service o Support the business processes and provide IT services that meet the particular business requirement o Improve productivity and efficiency due to knowledge and experience o Improved employee satisfaction and potential to improve staff retention levels o 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 classed as a process does not mean that the Service Desk is any less well organized, 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 Desk handles both Service Requests and Incidents. The Service Desk provides an effective interface to other activities such as Incident Management, Problem Management, Change Management, Configuration Management, Release Management, Service Level Management and IT Service Continuity Management

© 2006 IT Service Success

15

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.

© 2006 IT Service Success

16

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 when reporting an Incident. o Knowledgeable and helpful contact point, the user feels confident that the right people and focus has been applied to their 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: Really know and understand the user community. Understand the business drivers. Understand the Services used. Appreciate the impact of failure and downtime. Manage location, language and cultural challenges. Understand the management structure of the IT Service Organization. o An intelligent contact point that is helpful and works on behalf of the user. o o o o o o 1.6 Organization The Service Desk must ensure that it's organized well to provide: o o o o o o Appropriate hours of coverage. Levels of flexibility. Correct staffing levels. Appropriate skills provided. Appropriate knowledge. Suitable structure.

© 2006 IT Service Success

17

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 be fit for purpose and highly in tune with what the business users need. Operating standards and processes are required to maintain consistent quality of service. A "Central" Service Desk supports multiple locations and sometimes multiple geographies. The business is distributed. Centralization provides a consistent service experience. Standards are maintained and staffing levels and expertise can be controlled easier. This usually leads to lower overall operating costs. A "Virtual" Service Desk operation is location independent. Sometimes Service Desk Analysts work from home or across a number of locations. This is more common in large multi-national organizations where multi-language assistance is required. Users feel like they are communicating locally. Standard operating practices, processes and user experience must be upheld. Management of the "Virtual" Service Desk is more challenging due to the complexity, time zone difference and language differences. Usually a local or regional team leader or manager 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 7 X 365 support for large organizations or multiple global contracts. Service Desk support is routinely 'switched' across time zones to

© 2006 IT Service Success

18

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

© 2006 IT Service Success

19

1.9 Tools An Integrated IT Service Management Tool is a must for any effective IT Services Organization. Such tools provide the capability to log an incident or service request, record progressive actions, apply time and date stamps, automate escalation and notification events against the logged item and provide management information reporting at varying levels. The Tool must also be capable of providing workflow to enable individual tickets to be worked across the many ITIL processes. For example an Incident ticket can be assigned to a support group for investigation and diagnosis. An effective Service Desk may also utilize several other supporting tools 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 of inter-operability are enhanced. Such tools include: Known Error Database, CMDB and Diagnostic Scripts with Automated Resolution Actions. In addition, due to the volume and frequency of calls received by any Service Desk, a suitable call management system is typically required. Call management systems provide queuing capabilities, call routing and transfer, interactive voice response (IVR), and in more advanced cases computer telephony integration (CTI) functionality. Again, if this functionality is integrated within the overarching IT Service Management Tool, then the overall control and visibility of tickets logged will be considerably enhanced.

© 2006 IT Service Success

20

1.10 Metrics Typical Service Desk Metrics Include: o o o o o o o #calls taken, #incidents logged, #service requests logged, #calls abandoned (user hangs up), #calls answered within xx seconds, average call duration, calls waiting #calls logged per Service Desk analyst.

More advanced Service Desk Metrics include: o o o o o o #calls resolved first time, #calls passed to Support team x, #times a call was re-assigned, age of a call, average age of a call and #calls resolved within Service Levels.

An important aspect of the Service Desk operation is Service Quality and User Satisfaction. Feedback forms, sample call backs and workshops are common methods for determining how well the Service Desk is performing and is an excellent way to learn how the Service Desk can improve further. An Integrated IT Service Management Tool and Call Management tools provide the Service Desk with the capability of producing real-time and historic reports on a wide range of metrics. It is not the production of these reports that is important but the level of review, action and decisions taken on the information provided that really counts. The Service Desk Manager is responsible for the regular production of management information and reports that provide vital feedback on performance and improvement activities for IT Service Management

© 2006 IT Service Success

21

1.11 Challenges Typically the Service Desk faces many day to day, medium term and long term challenges. Included in these, but not limited to, are: Staffing levels. Staff skills and capabilities. Dealing with peaks in call volume. Managing high impacting incidents. 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 Organization changes/grows. o o o o o

© 2006 IT Service Success

22

2 Incident Management
2.1 Mission “The mission of Incident Management is to restore normal service operation as quickly as possible with minimum business disruption to ensure the best levels of availability and service are maintained” Remember: - Normal Service Operation - As Quickly as possible - Minimum disruption - Best levels of availability. 2.2 Goals The goals of Incident Management are to: o o o o o Restore normal service operation Minimize adverse business impacts Ensure the best possible levels of availability and service quality Improve staff utilization and efficiency Protect user and customer satisfaction

2.3 Definition What is an Incident? An incident is any event that: o o o o Is not part of the standard operation Is a deviation away from normal working practice Causes (or may cause) an interruption in service Causes (or may cause) a reduction in service quality

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

© 2006 IT Service Success

23

2.4 Scope The scope of Incident Management covers: o o o o Applications – Hardware Service Requests Service Availability Deviations from normal service (Service Levels)

It is important to remember that Incident Management handles regular Incidents, 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 manner o Proactive identification of enhancements or repeat occurrences o Improve the monitoring of performance against known Service Levels o 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 levels o 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: Detection and recording Classification and initial support Investigation, diagnosis and escalation (if required) Ongoing Incident ownership, monitoring, tracking and communication o Incident Closure o o o o

© 2006 IT Service Success

24

2.7 Incident Classification Incidents are classified at three stages: 1. Initially > to determine the type of Incident 2. Throughout the life of an Incident > to track changes in classification 3. At Incident Closure > to ensure the right classification for analysis and reporting. Examples of Incident Classifications include: o o o o o o o o Fault Operating System Error Message Bug Low Performance Hardware Server Configuration Set-up error

2.8 Escalation Incident escalation is critical to ensure that Incidents are managed throughout their overall duration. The timeliness of who attends to an Incident, when and what is done to close an Incident is assisted by Incident escalations. Typical examples of escalations include: o Transferring an Incident from second line support to third line support o 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 a special category of Incident - known as Major Incidents. These are Incidents that have a very high impact (real or potential) on the organization.

© 2006 IT Service Success

25

Typically Organizations have a specially defined set of escalation procedures for Major Incidents where senior business and IT Service Management are more frequently appraised of status, progress and closure 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 second line support teams) o Identifying, monitoring and making important decisions against metrics o 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 is paramount. Incidents are usually logged by the Service Desk and categorized before handing off electronically to an IT support function such as Desktop support. Here, Incidents are received and initial support, diagnosis and escalation can occur. Note that (typically) one overarching primary tool is used to store realtime data and information about the status, detail and progress of an Incident whilst other (local) tools are often used to identify and diagnose the Incident. Each support area usually has several tools that are application, Infrastructure or Service specific. These supporting tools are also vital for 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 (from users). This saves vital minutes and leads to a better hand-off to the support function, if needed.

© 2006 IT Service Success

26

2.11 Metrics The accurate capture, storage, manipulation and presentation of Incident Management metrics is vital to enable IT Service Management to 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 Monday morning) 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: Number of Incidents received, by category Average time to close an Incident (from receipt) Volumes of Incidents handled, by team or an individual Number of Incidents not closed successfully within agreed Service Levels and the reason(s) why o 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 must be viewed holistically and from a number of angles before management decisions are taken. Positively impacting one metric (e.g. Average time to close) can negatively impact another (e.g. Number of repeat Incidents). o o o o © 2006 IT Service Success 27

© 2006 IT Service Success

28

2.12 Challenges The Incident Management function face a number of day to day challenges: 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 Management Process. It is critical that users understand how to access the Service Desk to ensure that Incidents are correctly recorded and the management process begins. o Quality of Information: real-time information is open to people's interpretation, sources of information vary across the life of an Incident and facts may only come to light after the Incident has been closed. o Maintaining Momentum and Ownership: avoiding support teams taking too long to diagnose an Incident, avoiding scope creep whereby the clock is ticking and no positive decisions are being taken - or - managing to maintain control and ownership when much 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 restoration is possible; ensuring that resources are available if the Incident runs 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 to investigate the underlying root cause of an Incident. Performing the save (system dump) takes valuable minutes and therefore a 'call' has to be made - "restore now" V's "find the true root cause once and for all". o Incident Information Volumes: Excellent information management skills are required to correctly split, cut, slice and dice key data and views of this data from ALL the Incident Management data that is logged. The sheer volume of Incidents in some operations makes this challenging. - Being Proactive V's Reactive: Too many incoming Incidents can lead to a reactive culture and people feel 'burnt out' over time. If little proactive work occurs, then Incidents may recur in the Operation, fuelling further reactive effort and burn out. The cycle needs to be broken to have a positive effect in the medium term.

© 2006 IT Service Success

29

3 Problem Management
3.1 Mission The mission of Problem Management is to: “Minimize the adverse impact effect on the business if both Incidents and Problems caused by errors in the IT Environment and to proactively prevent the occurrence of Incidents, Problem and errors” 3.2 Goals The goals of Problem Management are to: o o o o o o Identify the true underlying root cause of Incidents Present workarounds and resolutions Initiate improvement actions prevent recurrences of Incidents minimize the adverse impact on the business 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 root cause". It is important to commit to memory the definitions and clear distinctions between: An Incident, A Problem and a Known Error. These definitions must be strictly adhered to.

© 2006 IT Service Success

30

3.4 Process The Problem Management Process consists of the following activities: Problem Control: o o o o Identification Classification Assign Records Investigation and Diagnosis

Establish Known Error Control: o o o o Error identification and recording Error Assessment Recording the error / resolution 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 satisfaction o Improve the opportunities for Organizational learning and proactiveness. o Support the Incident Management and Service Desk functions by providing constructive feedback on the quality of their work.

© 2006 IT Service Success

31

3.6 Relationship between Incident, Problem, Known Errors and Changes Four Key Terms It is important to understand clearly the relationship between these four terms: o Incident o Problem, o Known Error o RFC First, the easy and straightforward scenario: An Incident is an interruption to IT Service. Some Incidents occur and are closed with no further action required. Some Incidents require a change to be raised in order to close them. Therefore Incident Management will raise a request for change (RFC) to the Change Management function. Now, the more complex scenario: Following the occurrence of one or more Incidents, a Problem Manager may choose (or be asked) to raise a Problem Record. Remember - a Problem is the unknown cause of one or more Incidents. Once investigated and diagnosed, the Problem Manager may then raise a known error record. (Incidentally, a known error record could actually remain open indefinitely within a known error database if the IT Service Organization deems it not viable, say for reasons of cost, to raise a RFC and eliminate the root cause of the Problem). 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 is implemented 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 original

Incident record? Two scenarios are likely: Given the nature of Incident Management is it unlikely that the Incident record will still be open after an extended time period. Remember that Incident records may be closed by Incident Management when the Incident is closed I.E. Normal IT Service has resumed. So, If a satisfactory workaround has been deployed, and normal service is resumed, then the Incident record can be closed. This usually happens quite quickly in most organizations.

© 2006 IT Service Success

32

If the original Incident has no suitable workaround then the Incident Management function will pass the Incident details over to Problem Management as soon as deemed necessary. Problem Management will then work as described above, but the entire RFC cycle (described in Change) will take place with great haste to ultimately reach a point where a resolution can be deployed into production to restore normal service. At this point the Incident record can be closed (because normal service has resumed) and both the Problem and Known Error Records may be closed too. 3.7 Reactive Problem Management Reactive Problem Management has to effectively deal with new incoming Incidents. Problem Management will review Incident details, configuration details and any defined workarounds. Problem Management will then follow the Process steps of Problem Control and Error Control to effectively determine the root cause of the Problem and 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 Service Management 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' - which leads to proactive action. o Providing relevant and targeted information to other IT Service Management functions, such as IT Service Level Management.

© 2006 IT Service Success

33

3.9 Common Techniques There are several commonly applied Problem Management techniques that have been used in quality circles for many years: o o o o Kepner Tregoe Ishikawa Diagrams IS / IS NOT Force Field Diagrams

3.10 Major Problem Reviews Once a major Problem has been resolved, Problem Management can facilitate a Major Problem Review. All the staff involved in the resolution 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 an integrated toolset. Incident records should be easily accessible and capable of quickly creating a Problem Management Record using core data from the Incident record. From here any additional details added to the Problem Record will, in turn, be capable of transferring into a Change 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 integrated toolset. Even more powerful is when the toolset is configured in such a way that "time" is deliberately compared with the current status of the Problem - highlighting, for example, when a breach of an SLA is due in so many hours.

© 2006 IT Service Success

34

The toolset should be configured to assist all teams in the execution of their 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 times o Number of Problems, by category, to help drive trending information Additionally, Management will want to know where the 'pain' is continually coming from and how much impact/cost it is causing the business. These Problems should receive the highest attention and be eliminated from the environment. 3.13 Challenges The Problem Manager will face a series of challenges on a day to day basis 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 criteria established and agreed up front in order to do this without constantly seeking higher Management's approval. o Collaborating with multiple groups, sometimes across different geographies and companies (third parties), means Problem Management 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 are produced for IT Service Management.

© 2006 IT Service Success

35

4 Change Management
4.1 Mission The mission of Change Management is to: “Ensure that standardized methods and procedures are used for the efficient and effective handling of all changes, so that the 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 o o o o Ensure the efficient and PROMPT handling of changes Apply standard change procedures Minimize the impact of any Incidents Improve the quality and availability of IT Service. In addition, Change Management protects the current IT Service delivered to the business by ensuring that formal steps must be taken in order to implement new changes. If changes were not formally handled, then poor quality or ill thought through changes could be implemented and have a negative impact on IT Service, say by causing additional Incidents

© 2006 IT Service Success

36

4.3 Why Change Management? Changes to an IT environment, whether it be to a Server or an IT Application, can either come along: Reactively - for example, if an Incident occurs. Proactively - for example, as part of a Service Improvement Initiative or new Project. Therefore Change Management is a critical and absolutely necessary part of the IT Service Organization. Change Management provides a structured, controlled and authorized way for changes to enter the production environment. Change Management must: o Ensure that ALL changes are considered and handled appropriately o 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 to enter production. Change Management is the key guardian of Service Quality. This is a difficult and high profile role with the IT Service Organization. The Change Manager has to balance the impact, cost, benefits and risk or either approving OR not approving 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 Incidents o Improved overall ability to handle multiple changes in the correct sequence, allowing greater volumes of change to enter production - and therefore provide the business benefit they were intended to deliver. o Ability to temporarily 'freeze' (or lock-out) all Changes to provide total protection for IT Service. This usually occurs temporarily when the business has a unusually high volume of activity to perform, say a retailer over the last two weeks in December. It can also occur for one off events, say during the first two days of © 2006 IT Service Success 37

the business beginning to service a massive new customer contract.

© 2006 IT Service Success

38

Change Management is sometimes (incorrectly) criticized for 'slowing down' activities leading to the implementation of new changes. Such criticisms are usually from people who do not understand and appreciate the Change Management function. In modern Organizations, Change Management does not slow down the absorption 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 and Emergency. Each Category will determine how in-depth and timely the overall assessment and approval stages are. Ironically Emergency Changes are assessed by fewer people in less time - but often present the most risk to IT Service. Minor Changes will be reviewed and approved by the Change Manager and typically do not require the approval of the formal CAB (although some 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 by Senior IT and Business Management. Often the term "Routine" change is also used. These are special preapproved types of changes that present very low risk and potential impact. Typically these are logged and scheduled on the Change Management tool - but only require local area (e.g. Telecoms) approval.

© 2006 IT Service Success

39

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. The CAB is made up of a broad range of IT and business representatives, all of which represent a core part of the either the IT Service Organization or the business. The role of the CAB is to review, understand, assess and ultimately approve 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 to be reviewed by the CAB. Such Changes often include minor Configuration changes to Infrastructure or when small pieces of new functionality, that have been tested, are 'switched on'. However, these Changes are NOT exempt from the Change Management Process (they will still be raised and approved within the

© 2006 IT Service Success

40

controls and visibility of the Change Team) they just do not require the more detailed scrutiny of the CAB. It makes practical sense to not review every change otherwise the Process could be perceived to be cumbersome and 'slow' down the progression 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 change o Advise the Change Manager on which changes should be approved or not approved, and the reasons why o Advise on the actual scheduling and correct timing for the change to be implemented, avoiding negative impacts to IT Service. CAB Attendees include : o o o o o o o o o o Interested Business area representatives. Incident Management. Problem Management. Configuration Management IT Programme Managers. Technical Support Representatives. Suppliers, Maintainers and Developers. Experts and Technical Consultants. IT Service Managers. The Change Manager and Change team members.

The attendees are not limited to the above list, and will differ according to the needs of each Organization. Some Organizations choose to only invite certain CAB members when certain types of changes are scheduled for review. This helps to maintain the efficiency of the Change Process

© 2006 IT Service Success

41

CAB Emergency Committee The CAB Emergency Committee exists to provide an emergency service to review, assess and ultimately approve or not approve an emergency change. Oftentimes, the need for Change approval will not coincide or cannot wait for the next standard CAB meeting. This occurs most when either action is required to protect or restore IT Service (say, as the results of an Incident) or when some key component of a project has been incorrectly dealt with (say, a critical data file needs updating in realtime to ensure that another planned change will take place successfully). The CAB/EC is made up of a known sub-set of regular CAB members. The CAB/EC provides essential emergency assistance to the Change Manager to help deal with specific urgent, late or previously unrecognised Change requests. In such cases, it is typical for the CAB/EC meeting to take place via a conference call. Such conference calls can happen at any time including out of office hours and at weekends. 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 engage with others) is typically higher. Essentially, the CAB/EC facilitates a "fast tracking" of the normal Change Process to try to facilitate business need whilst protecting IT Service. A difficult balance! 4.7 Process Process Lifecycle The Change Process consists of the following core lifecycle stages: o o o o o o o o o o Logging and Filtering Prioritisation and Categorisation Impact and Resource Assessment Authorization Scheduling Change Design / Build Change Test Change Implementation Post Change Review Close

© 2006 IT Service Success

42

Important Activities There are several important activities that help to underpin the successful operation of Change Management: o Logging and Filtering of Requests to prevent duplicate or poor quality change requests entering the Change Management Process o Applying a 'Priority' to each Change. This will drive the speed of assessment and also the level of scrutiny that's applied by the CAB (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 the person who 'raised' the change). The assessment includes a review of impact, risk, resources and the required timing (schedule) of the Change. - CAB members will either approve the Change 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 specified implementation schedule. o The Change builder must also devise back-out plans. It's important for the CAB to see these and appreciate that in the event that something untoward happens, the Change can be backed 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 any negative impact to IT Service

© 2006 IT Service Success

43

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 workflow capabilities from: Incident, Problem and Configuration Management; as well as provide visibility for Change requestors, designers, builders and testers. The Change Management tool should be fully integrated with the Configuration Management function, particularly with respect to the identification, linking and real-time updates of the status of Configuration Items. The Change Management tool should also provide reporting functionality to enable Change to provide Management with historic and 'look ahead' reports. Such reports will be utilized within CAB and CAB/EC meetings. It is also important that 'one version of the truth' is maintained and protected at all times. Where multiple tools (or views of data) exist - Change Management must determine the sole source of Change information. Important decisions must only be made from one reference source - otherwise incorrect decisions will be taken and this may impact IT Service. 4.9 Metrics Key metrics for Change Management include: Number of Changes, by priority and category, and then status. Number of Changes rejected by CAB, and the reason(s). Number of Changes approved and awaiting Implementation Number of Changes currently scheduled. 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 next time. The goal is to minimize the number of Emergency Changes because these are considered higher risk. o Number of successful V's unsuccessful (failed) Changes, by category, by requesting area. This will help to identify where poor quality Changes are coming from and lead to recommendations for overall improvement o o o o o

© 2006 IT Service Success

44

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 the receipt and assessment of Changes. o Lack of control over the volume of emergency Changes and the level of influence Change Management have over this volume 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 the knock-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 Changes to support IT Service objectives and business requirements.

© 2006 IT Service Success

45

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 all Configuration 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 Release Management). 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 of Configuration Items (CI's) o Configuration Item (CI): any individual Infrastructure component or an item (for example an Incident Record) related to the Infrastructure 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 circuit board. 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 Service Organizations.

© 2006 IT Service Success

46

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 be considered in two dimensions: Across IT Services and Infrastructure - Down into CI's and different levels of Hierarchy. For example, Configuration Management will need to determine the scope of what CI's will be identified and managed across the huge range of it's IT Services and Infrastructure. Will all third party applications be included? Will the recently acquired third party data centre be covered and included in scope? Secondly, the CI's levels will need to be defined and managed down for each CI item. For example, take a typical PC. Should the CI level be: o PC o Keyboard  Mouse • Screen o CPU. Should Configuration Management also identify and control the CPU's CI's: o CPU o Circuit Board  Firmware • Chipset o Interfaces  Fan Clearly "Scope" is two dimensional and the scope selected needs to best service the needs of the IT Service Organization, to in turn, best service the business.

© 2006 IT Service Success

47

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's current status e.g. A certain Server currently has an Incident logged against it, so Change Management can easily see this and determine 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 currently running the same level of Operating System? o Supports Security Management (note: Not a Service Support or Service Delivery Discipline) by highlighting any "unknown" CI's for example an "unknown" Service is connected to the core network. 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 be referenced in a structured way.

© 2006 IT Service Success

48

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 and responsibilities, 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 various information on CI's including: names, owners, relationships, versions, status and identifiers. Naming conventions must also be established. o Control: This stage ensures that no CI is added, modified or replaced without the appropriate controls. All CI's will be under Change Management control. This stage also provides Management 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 and tracking of CI's. Accounting occurs over the lifecycle of a CI from order, receipt and implementation - through to ongoing status and finally withdrawal and disposal. This stage is used to establish baselines. o Verification and Audit: Checks to ensure that the CMDB reflects the physical configuration and vice-versa. For example: A check to ensure that the live environment is correct before a major Release. Automated audit tools should be used to assist the Configuration Team. Also included is the formal verifying of Release and Configuration documentation before Changes are made to the live production environment. 5.7 Relationships with other Processes Configuration Management is closely linked with other IT Service Support and Service Delivery Processes: o o o o Incident. Problem. Known Error. Request For Change o Change Authorized o Change tested o Implemented o Released

© 2006 IT Service Success

49

5.8 Key Terms CMDB The Configuration Management Database (CMDB) is designed to hold details of CI's, their attributes and their relationships. Another important purpose of the CMDB is that is enables other IT Service Processes to be able to use the information to support other processes at key stages. For example: - Incident Management will ensure that any CI currently out of normal service operation, is flagged as such in the CMDB. This in turn, allows Change Management to make appropriate decisions when assessing requested Changes. The CMDB is a complex relational database that enables real-time multiple access to many CI's. Therefore the structure, levels, organization and overall "correctness" of the CMDB is a critical underpinning feature of IT Service Management. Definitive Software Library The Definitive Software Library is a physical library which holds definitive and authorized versions of all Software. Any access to Software in the DSL is strictly controlled by Change Management and Release Management. It is the 'one version of the truth', in terms of trusted Software versions, as utilized in the live production environment Baseline Baseline - A set of CI's that have been frozen at a specified point in time. - A snapshot of the configuration acting as a key marker point to facilitate either progression of a Change or Release - or a reversal of a Change or Release. - The snapshot contains all structural and CI details at any particular moment in time. - The snapshot can act as a marker for Change or Release reversals should something go wrong. Therefore it is an important record of a particular 'moment in time'. Level of Control Level of Control - The Configuration Process aims to target maximum control with the minimum amount of records in the CMDB. This 'sweetspot' needs to be carefully thought through and planned. - Some CI's will deliberately have more details than others. Not all CI's are recorded to the same level. - What's appropriate to the Organization is what matters most. - Typically, Configuration Managers will start planning their CI levels and CMDB structure by looking at critical IT

© 2006 IT Service Success

50

Services and understanding what's important to record within relevant CI's.

© 2006 IT Service Success

51

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 of suitably 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 Processes such 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 with regular updates from all aspects of the IT Infrastructure and targeted IT assets. 5.10 Tools There are three important types of tool to consider for Configuration Management: The CMDB: This is the heart of any Configuration Management Process. The CMDB is the central storage area for the definition and status of all relevant CI's. The CMDB is a complex relational database that stores, updates, adds, removes and provides status reports on the CI's and their relationships at many different moments in time. The CMDB should be kept up to date at all times. However, in reality some aspects of the CMDB will only be as accurate as the last known update. It is often impractical 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 integrated IT Service Toolset is important and will help to ensure that information is shared in the right place at the right time. For example: details from Incident records should automatically update the status of relevant CI's. Similarly for Change: Any CI's currently having a Change logged against them should be marked as such within the CMDB. The integrated toolset will know this and can provide real-time, accurate

© 2006 IT Service Success

52

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

© 2006 IT Service Success

53

IT Asset "agents": Each Infrastructure and Software asset in the IT Environment will need to be registered and made known to the CMDB. Typically, assets run "agents" which are special pieces of software that are designed to talk to the CMDB at pre-defined intervals, or when certain events are triggered or closed. Agents can be stored locally, say on a router, and configured on that particular device. Agents can also be found within the CMDB itself and can go out and seek (auto discover) assets. Third party vendors often provide intelligent agent software for these devices. To avoid 'traffic floods' or unnecessary updates, some assets are configured for only major events whilst others are configured to tell the CMDB everything that happens. Again, the configuration of agents depends on what information the Configuration Manager requires within the CMDB. Sometimes, the CMDB will run at a pre-defined level of accuracy and only when necessary (say, before a major Release) will the Configuration Manager execute special routines to obtain a snapshot (Baseline) of absolutely everything. 5.11 Metrics The accurate capture, storage, manipulation and presentation of Configuration Management metrics is vital to enable IT Service Management to make effective decisions. The CMDB in conjunction with "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).

© 2006 IT Service Success

54

© 2006 IT Service Success

55

5.12 Challenges The Configuration Management function face a number of day to day challenges: o Designing the CMDB. Selecting the correct 'level' at which to record, process and manipulate CI's is a challenge. If the level is too low (detailed) then there may be too much data for the IT Service Organization to handle and effectively utilize. Too much data or an over-ambitious level of detail can present other Processes with a cumbersome quantity of data to handle. Too little data and the Processes do not receive useful information to leverage the power of the CMDB. o Maintaining the CMDB. Once the level of CI's is agreed and configured into the CMDB and agents, the challenge then becomes ensuring that the agents work as agreed and actually do populate the CMDB with the right information at the right time. Agents are software components and these fail occasionally 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 IT Organization. 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 that there are three related (lower level e.g. Keyboard) CI's for each known asset. 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. Most CMDB's are already fully integrated with the IT Service toolset. However, challenges can occur when you consider how to obtain information from another Vendors asset that uses a different way of communicating, say a different agent. Thankfully communication standards usually mean that this can easily be overcome - but there are exceptions. Sometimes, separate local CMDB's are needed to manage certain "islands" of CI's, which then feed the master CMDB. When purchasing new assets, the IT Service Organization needs to ensure that their agents are compatible with the selected CMDB - both now and in the future.

© 2006 IT Service Success

56

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 provided to the CMDB. Sometimes intelligent scripts are written and executed from 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 accurate maintenance and ongoing support of the CMDB.

© 2006 IT Service Success

57

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 IT Development and Project Management part of the IT Organization. Although staff in these areas will design, build, configure, test and implement systems and Infrastructures; it is Release Management's responsibility to ensure that this is achieved in a structured manner for anything 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 ensure that ALL aspects of a Release (technical and non technical) are considered together. To ensure that releases are implemented in a safe, structured and secure way that will protect the Live environment 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 and tested 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 unused licenses are identified and any refunds are claimed.

© 2006 IT Service Success

58

6.4 Appropriateness Release Management is most appropriate when the IT Service Organization has to: o Implement large or complex sets of Changes. o Manage a series of successive major Software roll-outs. o Group important Changes together to meet some criteria, say to comply with legislation by a certain date. Note - Not all Changes will be packaged into Releases. It is perfectly feasible for Changes to be individually considered by Change Management. However, it quickly becomes apparent that economies of scale, lower risk and better utilization of resources is achieved when a group of Changes are packaged together and handled as a Release. 6.5 Key Terms There are nine key terms that must be remembered: o Release: A collection of authorized Changes. These can be Minor, Major and Emergency. o Release Unit: A portion of the IT Infrastructure that can normally be released together. o Delta Release: A Partial release containing only those items that actually changed. o Full Release: A Release containing ALL the components of the Release unit, regardless of whether they have changed or not. o Package Release: A grouping of Full and/or Delta Releases usually recommended to meet some business need e.g. To provide stability to the Live Environment. o Roll-out: To deliver, install and commission new or changed CI's across the Organization. In this case, changes CI's make up a release, as defined above. o Definitive Software Library: A physical library (usually well protected, locked and fireproofed) containing Master copies of all authorized version of Software and their license agreements. This is strictly controlled by Release Management. Key considerations include: Media, Security arrangements, retention periods, audits, naming conventions and environments supported.

© 2006 IT Service Success

59

o Definitive Hardware Store: Special area set aside for the secure storage and protection of hardware spares. These will reflect the parts used within the Live environment. Such items may be used for testing or major Incident recovery but must be carefully managed and ultimately replaced if used. o Release Policy: An important document that states the roles and responsibilities for Release Management. Typically Policies contain information of the scope, standards and working practices of the Release Management function. This is to clarify to the other IT Service teams exactly how a Release is managed from planning through to implementation. 6.6 Relationship to Configuration Management It is important to understand the relationship between the Release Management Process and the CMDB. The CMDB holds the details of Software, Hardware, documentation and events. It contains event records of Changes and Releases. A Release record is always raised to satisfy one or more Request for Change. So the CMDB contains information that not only supports the Release process - but also holds information about the Release itself. The CMDB will be used to get information about a release and information about the target environment (Development, Test and Live). The Release Manager and the Change Manager have the capability of ensuring that the destination environment has the actual capability of receiving the Change e.g. The Operating System is at the correct level to run the Software that is transitioning.

© 2006 IT Service Success

60

6.7 Scope The scope of Release Management may be defined by: o The Release Policy document which outlines the role of Release Management in the provision of IT Service. o The relationships that Release Management maintains with Change and Configuration Management. o The criteria for when Changes should be packaged together into Releases. o The definition of when and what Release Management actually do across environments: Development, Test and Live. o The degree to which an Organization chooses to utilize Releases Management: for example Programme Managers who are responsible for a number of projects within a defined business or IT area or group 6.8 Benefits The benefits of Released Management should be considered when combined with Change and Configuration Management since the Processes are so inter-dependant. There are several key benefits: o Assurance that the right Software and Hardware is being used with the Live environment, minimizing the chances of any illegal or unauthorized Software or Hardware is used. o Supports the improvement of IT Service Quality, since there will be a greater success rate for the implementation of new Releases, which in turn means less impact or downtime for the business. o Enables the IT Service Organization to handle complex Changes as well as a greater number of overall Changes by releasing them into the Live environment in Packages. o Improves the utilization of building, testing and implementation resource.

© 2006 IT Service Success

61

6.9 Process The Release Management Process consists of a number of logical steps that may be considered in line with the environments that these steps are carried out in. Typically, most Organizations have a minimum of three distinct environments: Development, Test and Live. These can be supplemented with other specialized environments such as Operational Testing (a distinct type of Test environment) and Pre-Production (a true "mirror" of the Live environment - but considered part of Test). Process Stages include: o On Development: Defining and publishing the Release Policy (See Key Terms) and Release Planning. o On Test Environments: Developing (or purchasing) Software, Building, Configuring bespoke packages, performing fit for purpose Testing, Release acceptance, roll-out planning and beginning the communication and training for the implementation of the Release. o On the Live environment: The distribution and installation of the Software; and finally the commissioning of the Software. Key considerations here include: o Building / Configuring Packages: Components should be assembled and built in a controlled manner using automated tools where possible. This improves control and visibility and minimizes human reliance. o Testing and back-out plans: All releases must undergo careful testing before implementation into the live environment. Workable back-out plans should exist to enable the Release to be quickly reversed should an untoward event occur. The back-out plan should also e tested to ensure that it works successfully.

© 2006 IT Service Success

62

6.10 Release Management's Responsibilities The Release Manager has several key responsibilities: o To manage the overall efficiency and effectiveness of the Process o To ensure that suitably skilled and experienced staff are available to manage Releases. - To work with the Change and Configuration teams to ensure that the quality of the Release and the way it is progressed from Development, through to Test and ultimately into Live is maintained. o To work with Development staff and Project Staff to ensure that Release Integrity is maintained. o To produce regular management information reports that clearly show the status and progress against plan of a particular Release. o To identify and help improve the quality of the Process. 6.11 Integrated Plans Many IT Service experts claim that integrating Release, Change and Configuration plans offers considerable advantages. Remember: o Without Change and Configuration Management, Release Management is limited in it's ability to achieve it's goals. o Changes will not be properly assessed and authorized. o Configuration items will not be under the control of a CMDB, so valuable CI information will not be available to help package and control Released across the Development, Test and Live environments. It is therefore recommended that a consolidated Change, Configuration and Release plan is created for all of the IT Service Organization to adhere too, and measure their progress against.

© 2006 IT Service Success

63

6.12 Tools Release Management will benefit significantly from the use of several tools: o The Integrated IT Service Tool. (See Relationship to Configuration Management). o The CMDB. (See Relationship to Configuration Management). o Local Environment Tools: such as test management tools, code packing tools and resource planning tools. Such tools provide automation, real-time and historic reporting as well as help to improve the overall management of each environment. o Asset Management Tools: one that is capable of managing and tracking an asset across it's entire life from selection and purchase, through to delivery, build, test, implementation, maintenance and eventually it's decommissioning. Such tools are typically used by Financial functions. 6.13 Metrics Release Management is concerned with the following metrics: o Release Records, stored within the CMDB, that describe the contents and details of a Release o The status of components at a CI level within the CMDB for particular environments. o The number of CI's that are affected by a particular Release. o The number and type of Change Records that make up a Release. o The successful progression of Change records as the Release progresses across Development, Test and into Live. 6.14 Challenges Release Management may encounter several challenges: o Avoidance or circumvention to policy, procedures and working practices. o Unclear ownership of activates across Development, Test and Live environments between IT Service Staff and Development / Operational Staff. o Senior Management pressure to roll out a Release before it has been fully tested, or it is considered fully ready. o Lack of clear understanding about what exactly is contained within a Release leading to misconceptions on implementation. © 2006 IT Service Success 64

o Lack of support from environment staff to enable Releases to progress according to planned time scales.

© 2006 IT Service Success

65

7 Capacity Management
7.1 Mission The Mission of Capacity Management is to: “Understand the organizations operation and IT infrastructure to ensure that all current and future capacity and performance aspects of the business requirements are provided cost effectively at the right time” Effective Capacity Management means "No Surprises!" 7.2 Goals The goals of Capacity Management are to: o Balance Capacity Demand against Capacity Supply in a cost effective and timely manner. o Understand current and future needs. o Ensure that sufficient (not excessive) Capacity always exists. o Ensure that IT Capacity is cost justified. o To be forward looking and pro-active. In other words: o Having the appropriate capacity in place and making the best use of it. o Getting the timing right: too soon is money wasted but too late causes Incidents! 7.3 Scope The scope of Capacity Management can be wide ranging, depending on any particular IT Service Organization. Typical Capacity Management functions will cover: o o o o o o All applications All systems All Infrastructure All Networks All peripherals Human Resources (where necessary to avoid delays to the timely provision of Capacity).

© 2006 IT Service Success

66

This scope covers three core areas:
o Business Capacity Management (BCM): What Capacity the business needs to operate. o Service Capacity Management (SCM): What Capacity the actual Services need to operate. o Resource Capacity Management (RCM): What Capacity the Technology Resources need to operate e.g. Disk, CPU, Broadband Connections.

7.4 Benefits o There are many benefits of Capacity Management: o Increased efficiency and cost savings. o More economic use of the IT services. o Removal of spare and unnecessary capacity and optimizing current equipment. o Reduce or eliminate unnecessary 'panic' buying. o Reduce the risk of performance problems. o Improved forecasting. o Proactive awareness of potential Capacity issues. o Improved relationships with customers and users. o Service improvements seen through better control. o Reduce the need for reactive support. 7.5 Process

o o o o o o

Performance monitoring Workload monitoring Application sizing Resource forecasting Demand forecasting Modeling

© 2006 IT Service Success

67

7.6 Capacity Manager's Responsibilities The Capacity Manager is responsible for: o Monitoring the performance and the throughput of IT services and their supporting components. o Tuning activities to make efficient use of resources. o Understanding current demands of IT resources and producing forecast for future requirements. o Influencing the demand for resource, in conjunction with other IT Service Management processes. o Producing a Capacity Plan and predicting IT resources needed to achieve agreed SLAs. o Ensuring the availability of appropriately skilled and experienced staff to run and improve the Process. 7.7 Capacity Database The Capacity Database holds Capacity data referring to: o The Business o IT Services o Technology o Finance o Utilization o Performance o The Capacity Database interfaces with, or is integrated with, the CMDB. Note: Do not confuse the Capacity Database with the CMDB. They are NOT the same thing! The Capacity Database is the absolute cornerstone of Capacity Management. It will be used to produce critical reports such as forecasts and plans as well as performance and Capacity reports. This will hold existing and future capacity information. In reality, it is unlikely to be single database, but will probably exist in more than one location and will contain many types of data, for example: o o o o o Business data, Service data, Technical data, Financial data and Utilization data.

© 2006 IT Service Success

68

7.8 Tools The Capacity Management function should have tools such as the following: o The Capacity Database (see separate description). o Performance management tools. o Resource management tools to enable modeling, including application sizing. o Demand and workload management. o Reporting tools (production of the Capacity plan). Remember: the Capacity Management Database is used as the basis for the production of all Capacity Management reporting. This will hold existing and future capacity information. It is unlikely to be single database, but will probably exist in more than one location and will contain many types of data.

7.9 Metrics A multitude of metrics can exist within each of the three core areas that Capacity Management focuses on: Business Capacity Management (BCM): o Existing SLAs o Future Service Level Requirements (SLRs) o Business Plan o Capacity Plan o Modeling Techniques , Analytical, Simulation, Trending and Baselining o Application Sizing Methods Service Capacity Management (SCM): o Service Levels o Systems, networks and service throughput and performance metrics o Monitoring, measurement ,analysis, tuning and demand management Resource Capacity Management (RCM): o Utilization metrics of the current technology o Forecasted metrics for future or alternative technologies o Resilience of the current systems and services.

© 2006 IT Service Success

69

© 2006 IT Service Success

70

7.10 Challenges Capacity Management face a number of challenges: o o o o o o o o o Customer requirements exceed technical capacity limits. Over expectation of the benefits realized from tuning. Unrealistic performance figures from equipment suppliers. Lack of business information due to security or commercial restrictions. Inaccurate or incomplete business forecasts. Incomplete or inaccurate information from IT support functions. Too much data - data overload - unable to "see the wood for the trees". Lack of financial resources. Lack of technical resources with the right skill set.

© 2006 IT Service Success

71

8 Availability Management
8.1 Mission “Availability Management ensures services are available when the customer needs them” 8.2 Goals The Goals of Availability Management: o To optimize the capability of the IT infrastructure and supporting organization to deliver a cost effective and sustained level of availability that enables the business to satisfy its objectives. o This is supported by the Availability Plan. This plan is a long term plan for the pro-active improvement of IT Availability within imposed cost constraints of the business. The plan must contain: goals, objectives, key deliverables and describe the operation of the function in respect of the goals 8.3 Scope The scope of Availability Management works right across the IT organization and: o Optimizes availability levels by monitoring and reporting all key elements. o Determines availability requirements. o Produces the Availability Plan. o Collects and reports on Availability data. o Ensures SLAs are met by monitoring against them. o Continuously reviews and improves levels of service availability. o Works with many other IT service teams to ensure receipt of inputs and delivers outputs to them.

© 2006 IT Service Success

72

8.4 Key Terms There are 5 elements of Availability Management: Availability: The agreed service hours when a component (e.g. resource, hardware, software) is available. Often expressed as a percentage and then documented in the SLA (e.g. Available time / Agreed Service Time * 100). Reliability: The reliability of a component to perform a required function under stated conditions for stated period of time. Expressed as MTBF (Mean Time Between Failure) or MTBSI (Mean Time Between System Incidents), or number of breaks in a period. Also documented in the SLA. Maintainability: The ability to restore services or components back to normal operational state. Expressed as MTTR (Mean Time To Recover). Also documented in the SLA. Serviceability: The support for which external suppliers can be contracted to provide parts of the IT infrastructure. (Documented in the Underpinning Contract). Security: Concerned with the security of the services ensuring that the service is delivered within secure parameters and that confidentiality, integrity and availability are not compromised. 8.5 Benefits There are many benefits of Availability Management: o Effective Availability Management will influence customer satisfaction and help to maintain or grow future business and profitability o Effective Availability Management will increase the overall levels of confidence that management actually has in the IT organization. More specifically it ensures: o A focus point, across the IT Organization, that helps to drive up levels of availability. o The frequency, duration and therefore impact of IT service failures can be reduced over time

© 2006 IT Service Success

73

o IT Services can be designed with the appropriate level of Service Availability. o This function provides true end-to-end availability reporting to ensure that the SLM function can accurately report service availability within their SLA's.

8.6 Techniques In addition to tools there are a number of techniques that could be used to provide a framework for forecasting availability: 1. CCTA Risk Analysis and Management Method (CRAMM). Used to identify security countermeasures for the protection of IS systems. CRAMM has a built in ‘what if’ facility so that scenarios can be run to assess the impact of change. 2. Component Failure Impact Analysis (CFIA). A simple technique that can be used to identify IT services that are particularly vulnerable to failure and the configuration items on which a large number of services are dependant. This is achieved by populating a grid detailing configuration items on one axis and the IT Services on the other axis. Each configuration item would then be categorised as: If failed does not affect IT service If failed causes the IT service to be unavailable Is there an alternate configuration item that can provide the service? Is there an alternate configuration item but the service has to be recovered? Completion of the grid provides an easy way to identify the configuration items on which a large scale number of services are dependant, or you can identify which IT services are complex and are vulnerable to failure. 3. Fault Tree Analysis (FTA) A technique that can determine the chain of events that causes disruption to the IT service. It examines the consequences of single vents of chains of events in determining whether there is a failure in the IT infrastructure.

© 2006 IT Service Success

74

© 2006 IT Service Success

75

8.7 Process Availability Management has numerous inputs and outputs as part of the process : Inputs: o Business availability requirements o Business impact assessment o Availability, reliability and maintainability requirements o Incident and problem data o Configuration and monitoring data o Service level achievements Process: o Optimization of availability by monitoring and reporting all key elements. o Determining availability requirements in business terms. o Predicting and designing expected levels of availability and security. o Production of the Availability Plan. o Collecting, analyzing and maintaining and reporting availability data. o Ensuring SLAs are met but monitoring against them, including OLAs. o Continuously reviewing and improving availability. Outputs: o Availability and recovery design criteria o IT infrastructure resilience and assessment o Agreed targets for availability and maintainability o Reports of availability, reliability and maintainability achieved o Availability monitoring o Availability improvement plans

© 2006 IT Service Success

76

8.8 Tools The Availability Management tool should have the following facilities: o Availability monitoring, calculating and reporting. o Availability modeling. o Incident prevention. The tool will have multiple inputs of data from a variety of sources and some manual capture and data entry may be required.

8.9 Metrics The IT Availability Metrics Model (ITAMM) assists in assessing a range of metrics and perspectives that should be considered when establishing availability measurement and reporting. Measurements need to be meaningful and add value. Often the data required to calculate metrics will be taken from a number of sources and requires a lot of manual effort. Here are some common metrics used for Availability Management: Service Availability is a measure of the time that the service is actually available when compared with the scheduled time. It is often calculated and presented as a % of the actual hours required, for example: Actual hours / required hours * 100% = availability Service Reliability is usually measured as: o Mean Time Between Service Interruption (MTBSI) o Mean Time Between Failure (MTBF) Service Maintainability is usually measured as: o Mean Time To Repair (MTTR)

© 2006 IT Service Success

77

8.10 Challenges There are several challenges to consider: o Avoid availability measurements that mean nothing to the business or the customer. o Overcoming restrictions on not being able to measure availability at the point of service delivery. o Identifying and securing skilled resource for the role. o The justification of costs to management, for example the cost of some countermeasures such as hardware which may be seen as redundant kit and unnecessary. o Lack of senior management buy-in. o Undue reliance on other Service Management functions being in place, for example Service Desk, Configuration Management and its associated CMDB. o Lack of suitable software - although tools are available, information is gathered from a number of sources, with a lot of information being gathered manually. o Dependency on suppliers, in particular for maintainability and reliability. o Difficulty in determining and understanding the business and customer availability requirements.

© 2006 IT Service Success

78

9 IT Service Continuity
9.1 Mission The Mission of IT Service Continuity: “To manage an organization's ability to continue to provide a known, agreed and pre-determined level of IT Service, to support business requirements, following some kind of interruption to the business. To recover IT Service and Technology within required and agreed time scales to support the overall Business Continuity process” 9.2 Goals What are the goals of IT Service Continuity? o Reducing the immediate and ongoing impact of a failure or disaster on the business. o To quickly restore IT Services to at least the minimum level that supports the business. o Prevent the loss of customer or business confidence, say caused by an inability to recover service within agreed time scales. o Reduce the overall vulnerability and risk to the business of a failure or disaster through effective risk assessment, analysis and risk management. o To produce IT service recovery plans that are fully integrated with, and fully support, the organization's overall business level continuity plan. 9.3 Scope Security Management impacts all Service Management disciplines. In particular it should be reflected in the levels of confidentiality, integrity, and availability required within the Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) under Service Level Management. There is also a close relationship between IT Security and Continuity Management in that each relies heavily on the tools and techniques of risk management.

© 2006 IT Service Success

79

9.4 Benefits What are the benefits of IT Service Continuity Management? o Management of risk leads to reduction of likelihood of disaster occurrence. o Management of risk leads to reduction in impact if disaster did occur. o Meeting regulatory requirements. o Improved relationships between the IT organization and the Business. o Greater awareness by the IT organization of the business service priorities and needs. o Capability to recover and restore IT services in the order that the business really needs to have the best chance of recovering. o Reduction in insurance premiums (lower risk). o Increased confidence in IT's ability to actually recover (since it's been tested!) o The perceived credibility and professionalism of IT is increased 9.5 Process The IT Service Continuity Process is in 4 stages and purposely includes business level terms, like Business Continuity Management. Remember that IT Service Continuity is a critical sub-component of the overall Business Continuity Management Process: Initiation of Business Continuity Management (BCM). o Requirements and Strategy for BCM o Business Impact Analysis o Risk Assessment Business Continuity Strategy o Implementation. o Organization and Implementation Planning o Implement Stand-by Arrangements o Develop Recovery Plans o Implement Risk Reduction Measures o Develop Procedures o Initial Testing o Operational Management:

© 2006 IT Service Success

80

o Operational Assurance: (There are five activities that lead to this being achieved) o Education and Awareness o Review and Audit o Testing o Change Management o Training

ITIL also prescribes the benefits of continual improvement - so you should remember that after stage 4 - you should be identifying and implementing ongoing improvements to improve quality and reduce costs.

9.6 Metrics o Co-operation and commitment with organizations key stakeholders to create and execute a recovery plan o Effective installation of backup tools o Effective implementation of configuration management process and training o Successful testing of the Service Continuity Plan 9.7 Challenges A prevailing "That's not likely to happen to us!" attitude to risk. o Therefore a subsequent lack of investment in resources and time to perform the activities. o Lack of time and available skilled resources to be involved in risk assessment, testing and rehearsing IT service recovery activities. E.g. "We're too busy delivering live service to rehearse for a disaster that may or may not happen!" o Lack of business involvement in proper planning, risk assessment and testing leads to the IT Service Organization making best estimates about service recovery options. o IT is more advanced than the business in it's overall approach to Business Continuity - leading to well structured IT recovery but poor business involvement and execution

© 2006 IT Service Success

81

10 Service Level Management
10.1 Mission The mission of Service Level Management is to: “Maintain and gradually improve business aligned IT service quality through a constant cycle of agreeing, monitoring, reporting and reviewing IT service achievements and through instigating actions to eradicate unacceptable levels of service” Remember: o o o o o o o o Maintain Improve Business Aligned Quality Review Achievements Instigate Action Eradicate Continuous Improvement

10.2 Goals Service Level Management is the process that manages and improves agreed levels of service between two parties: o The provider, who may be an internal department, for example the IT department or building services, or an external outsourced company or third party supplier. o The receiver of the service, i.e. the customer who pays the bills. Service Level Management ensures that the service targets are documented and agreed in SLAs (Service Level Agreements) Service Level Management monitors and reviews the actual service levels achieved against their agreed SLA targets. Service Level Management also plays a proactive role in the ongoing improvement of the service levels within the imposed cost constraints.

© 2006 IT Service Success

82

10.3 Scope The scope of SLM covers: o Negotiating and agreeing service requirements with the customer. o Measuring and reporting of actuals against target, resources require and cost of service. o Continuously improving service lines in line with business processes. o Co-ordinating other Service Management functions and 3rd party suppliers. o Reviewing SLAs to meet changed business needs. o Reviewing SLAs to resolve major service issues. o Producing, reviewing and maintaining the Service Catalog 10.4 Benefits The benefits of SLM are: o Both parties have clear view of responsibilities and specific service targets. o Service monitoring and reviews will identify weak areas, therefore enabling the provision of higher quality IT services. o Prevent misunderstandings between customers and IT providers. o SLM underpins Supplier Management, the SLAs are a key part in managing the supplier relationships o IT Services will be designed to meet the SLRs (Service Level Requirements). o SLAs can be used as a basis for charging and demonstrating to the customer what they receive for their money! o OLAs and support contracts with external suppliers are aligned with the business services required

© 2006 IT Service Success

83

10.5 Process The SLM process involves the following: o Gain an understanding of the customer’s business processes and drivers. o Negotiate and agree service requirements and expected service with customer and the IT Service provider. o Produce and document a SLA that all parties agree to. o Measure and report actuals against targets. o Continuously look to improve the service lines in line with changing business needs. The SLM process creates a framework that disciplines both the customer and the provider. SLM encourages the customer to consider, document and define their real business needs. SLM can make the provider more focused and accountable.

10.6 SLA Content Typically the key elements of a Service Level Agreement are: o General details (brief description, parties, signatories, date, and version number). o Service Hours. o Service Availability (%) and reliability levels (MTBF). o Support Levels. o Functionality. o Terminal Response Times. o Throughput and batch turnaround times. o Printing. o Contingency and Security. o Charging, Administration and review timetable. o Glossary

© 2006 IT Service Success

84

10.7 Tools An accurate monitoring tool is key to the content of the SLA. It is important that metrics included in an SLA can be monitored. If you can't monitor it, you can't report on it, therefore you can't include it in your SLA ! SLM will rely on the tools utilized by other support functions, for example Service Desk tool to provide incident reports, Availability Management to provide availability % actuals, Capacity Management for throughput information 10.8 Metrics The metrics produced by SLM will be driven by each individual SLA. A key output of the metrics is the continuous service improvement program in line with the business processes and also the ability to identify weak areas quickly. 10.9 Challenges The SLM function face a number of challenges: o Ensuring that targets are achievable before agreeing to them, i.e. don't be over ambitious by trying to give the customer what they want when you cant deliver. o Don't be under ambitious, if you set targets that can be easily achieved it may be seen as an excuse for a reduction in service quality. o Having the right monitoring tools in place to measure the actual achievements, this will avoid disputes with the customers. o SLAs may not be supported by adequate underpinning contracts. o The content of the SLA may be too lengthy or not business focused, therefore not used. o SLM and other IT support functions do not fully understand the business drivers or the need for the requested service levels. o Ensuring that adequate resources and time to support, measure and report on the SLAs

© 2006 IT Service Success

85

11 Security Management
11.1 Mission The mission of IT Security Management is: “to manage information security effectively within all service activities” NOTE : IT Security Management is not responsible for ensuring that implementations of new IT Services are compliant – this is the responsibility of the Availability manager to ensure security requirements are clearly defined and incorporate into the solution. 11.2 Scope o To ensure compliance with security requirements for new and existing SLAs o To meet external requirements that are not defined in contracts, policies and legislation o To provide a basic level of information relating to security to information systems independent of external requirements o To ensure that effective security measures are taken at strategic, tactical and operations levels 11.3 Benefits o Provide significant added value to information system o Contributes to the continuity of the organization o Assists the organization in meeting its objectives

© 2006 IT Service Success

86

11.4 Process IT Security Management focuses on the following: o Confidentiality o Ensuring no unauthorized access to systems or data o Integrity o Ensures data / information is accurate and complete o Availability o Ensures authorized information is accessible o Privacy o Allowing owners of data/information to restrict access o Verifiability o Ensures data/information is only used for its intended purpose o Ensures security measures are effective

11.5 Relationships with other disciplines IT Security Management has the following key relationships: o Service Level Management This relationship ensures that the services that are about to be provided to customers are defined and achieved to include sufficient security measures. o Availability Management In order to benefit from the various security measures, for example confidentiality and integrity which can benefit system availability – it is key that there is sufficient co-ordination between IT Security Management, IT Service Continuity and Availability Management. o Capacity Management The majority of Capacity Management activities can affect availability, this will also impact IT Security Management. o IT Service Continuity Management This is a key input to the SLA agreed with the customer. As security is a key input to the Continuity plan agreed within the SLA this is an important relationship.

© 2006 IT Service Success

87

11.6 Metrics o # of security incidents recorded o Type of security incidents recorded o Impacts of security incidents

11.7 Challenges o o o o Peoples commitment to IT Security Peoples attitude Awareness throughout the organization Lack of systems to assist with IT Security (i.e. detection systems)

© 2006 IT Service Success

88

Organizations That Promote ITIL
The following are key organizations that promote and support the IT Service Management philosophy and the importance of ITIL. OGC The OGC is the Office of Government and Commerce. The OGC produce the IT Service Management volumes. ITIL® is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce. IT Infrastructure Library® is a Registered Trade Mark of the Office of Government Commerce. www.ogc.co.uk www.itil.co.uk TSO TSO is the largest publisher in the UK by volume, publishing over 15,000 titles a year. The TSO are the publishing partner to the OGC. All copies of ITIL books can be purchased from the TSO. www.tso.co.uk/itil www.tsoshop.co.uk ISEB It began its life as a single qualification, the NCC (National Computing Centre) and BCS collaborated on developing the 'Certificate in Systems Analysis and Design' for the Systems Analysis Examination Board. Due to the development of further qualifications the Systems Analysis Examination Board made the decision to change its name to ISEB. The ISEB portfolio now offers a large number of IT qualifications in a variety of disciplines. ISEB qualifications add value to professional careers by providing both the means and the platform for recognition and enhanced career development. www.bcs.org

© 2006 IT Service Success

89

EXIN EXIN, the Examination Institute for Information Science, is a global, independent IT examination provider. EXIN is well-known worldwide for its ITIL certificates in IT Service Management. With examinations like ITIL, ISO 20000/SQM, MOF, ASL, DSDM, MOF and ISPL, EXIN plays an important role in the development of international qualification standards. EXIN exams are available in ten languages. www.exin-exams.com

ITSMF The itSMF is the only truly independent and internationally-recognized forum for IT Service Management professionals worldwide. The itSMF is a not-for-profit organization is a prominent player in the on-going development and promotion of IT Service Management "best practice", standards and qualifications and has been since 1991. The itSMF provides an accessible network of industry experts, information sources and events to help you and your staff address IT service management issues and help you achieve the delivery of high quality, consistent IT service internally and externally through the adoption of "best practice". The itSMF now boasts over 2500 member companies, blue chip and public sector alike, and international itSMF Chapters www.itsmf.com

© 2006 IT Service Success

90

THOMPSON PROMETRIC Thomson 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 that includes test development, test delivery and data management capabilities. Since 2002, Thomson Prometric and EXIN have collaborated on the delivery of the ITIL Foundation exams in English. As a result, EXIN can improve the accessibility of EXIN's IT Service Management (ITIL) exams for more candidates worldwide, and test them in the highly secure, consistent Thomson Prometric Testing Center environment, while providing candidates with improved flexibility in choosing both the test date and location. www.prometric.com

© 2006 IT Service Success

91

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer: Get 4 months of Scribd and The New York Times for just $1.87 per week!

Master Your Semester with a Special Offer from Scribd & The New York Times