Your SlideShare is downloading. ×
An Introduction to ITIL
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

An Introduction to ITIL

1,498

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,498
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
104
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Triumfant ITIL Primer White Paper  An Introduction to ITIL 
  • 2. Overview:  Definition, History, Purpose and Relevance  ITIL stands for Information Technology Infrastructure Library, and is literally a set of books  developed by the British government. Figure 1 shows the various books that comprise the  library. The Central Computer and Telecommunications Agency (CCTA) of the U.K. was the  original owner of ITIL. As of 2001, however, the CCTA became part of the Office of Government  Commerce (OGC), which is the current owner of ITIL today.  ITIL was developed under the premise that organizations were becoming increasingly  dependent upon IT to fulfill their corporate objectives. This growing dependency gave way to the  need for those IT services to maintain quality standards that corresponded to the objectives of  the business, which in turn relate to the requirements and expectations of the customer. ITIL  provides a set of best practices for IT service processes to provide effective and efficient  services in support of the business.  ITIL is not a standard. BS15000 is a British standard for IT Service Management based heavily  upon ITIL. ISO20000 has been proposed as the international version of the BS15000 standard.  ITIL is also a core part of the foundation of Control Objectives for Information and related  Technology (COBIT). COBIT is the framework of choice for external auditors performing IT  audits for Sarbanes­Oxley (SOX). Together, ITIL and COBIT provide a formidable combination  to achieve SOX compliance.  ITIL has been rapidly adapted across Europe for best practices and is rapidly gaining  acceptance across the globe. As SOX and other IT governance issues become driving forces  for many organizations, ITIL will be looked at seriously as a key component for achieving  compliance within IT for those governance bodies. Triumfant ITIL Primer  Page 2 
  • 3. Figure 1: ITIL Publication Framework  IT Service Management  Much of the focus on ITIL is within IT Service Management (ITSM). ITSM pertains to the  delivery and support of IT services that meet the requirements of the business organization.  This primer will focus on the Service Support domain. Table 1 shows the various components  contained within ITSM.  Table 1: IT Service Management Processes  Service Support ­ Operational Processes  ITIL Service Support generally focuses on the daily operation and support of IT services and is  broken down into five main processes and one key function. These processes, functions, and  their relationships to one another are illustrated in Figure 2. Triumfant ITIL Primer  Page 3 
  • 4. Figure 2: ITIL Service Support  The Service Desk  The service desk is the only function within the ITIL framework. It handles incidents, problems  and questions and is responsible for resolving incidents as quickly as possible. The service  desk usually serves as the single point of contact for customers and is integrated into other  service management processes and business processes. There are various classes of service  desk that correspond to the capabilities required within a given IT organization. These  capabilities can range from simple call routing to expert­level specialists resolving incidents.  Incident Management:  The goal of the Incident Management process is to restore service as quickly as possible with  minimal disruption to the business. This allows the highest levels of service and availability to be  maintained. An incident comprises any event, not part of a standard service operation, which  causes, or may cause, an interruption or reduction in quality of service. Incidents are typically  broken down into two categories—service requests and all other incidents. Service requests  include requests for information or documentation and non­urgent requests (e.g., How To's,  Password Resets, etc.).  Important ITIL Terms  Incident: Any event, not part of a standard service operation, which causes, or may cause, an  interruption or reduction in quality of service. Triumfant ITIL Primer  Page 4 
  • 5. Problem: A condition characterized by multiple incidents exhibiting common symptoms, or a  single significant incident for which the root cause is unknown.  Known Error: A problem for which the root cause and a workaround have been determined.  ITIL Incident Management Process  As shown in the diagram above, there are many activities that make up Incident Management.  These include: · Incident Acceptance and Recording ­ Incidents arrive at the service desk via many  possible avenues including phone, email, fax, self­service portals, etc. Regardless of the  method, a record of the incident is recorded. · Classification and Initial Support ­ Incidents are coded by type, status, impact,  urgency, Service Level Agreement (SLA), priority, etc. The service desk may give the  user suggestions to solve the issue, even if they provide only a temporary workaround. · Service Requests ­ If the incident is a service request, the appropriate procedure for  that request is initiated. · Matching ­ Incidents are investigated and initially compared to a known error database.  This database typically comprises a common knowledge base utilized by the service  desk in addition to what an individual service desk administrator may already know. If  the incident is not recognized as a known error, it is then compared to entries within  the known problem database. Here, problem records identify open problems that  are currently under investigation or pending change resolution. If the incident Triumfant ITIL Primer  Page 5 
  • 6. matches either a known error or known problem, it is matched to a known solution or  workaround, respectively. · Investigation and Diagnosis ­ If there is no match of known errors or known problems,  the incident must be further investigated. This involves gathering as much information as  possible about the incident to determine how to restore service as quickly as possible. If  first level support within the service desk cannot determine a solution, the incident is  escalated to second level support. This escalation process continues as appropriate  according to SLAs, internal procedures, etc. If no resolution can be found, the incident is  declared a problem and the Problem Management process is initiated. · Resolution and Recovery ­ Once a solution is found, the issue is resolved by restoring  services to normal operation. · Closure ­ After the user verifies that service has been restored satisfactorily, the incident  is closed.  Problem Management:  The Problem Management process has the goal of minimizing the adverse impact of incidents  and problems resulting from errors within the IT infrastructure, and to prevent the recurrence of  incidents related to those errors. There are two different types of activities within Problem  Management—Proactive and Reactive.  Proactive Problem Management: Prevents incidents from occurring by identifying weaknesses  or errors in the infrastructure and proposing applicable resolutions. Although most organizations  aspire to implement this portion of Problem Management, few are able to achieve success for  reasons to be discussed later.  Reactive Problem Management: Identifies the root cause of past incidents and proposes  improvements and resolutions. Figure 4 illustrates how Reactive Problem Management is  broken down into two areas: Problem Control and Error Control. Triumfant ITIL Primer  Page 6 
  • 7. Problem Management Process  Problem Control:  Identifies underlying root causes of incidents to prevent future recurrences.  Problem Control consists of the following activities: · Analysis ­ Information is gathered to be analyzed from various sources including  outputs from various ITIL processes such as Incident Management, Capacity  Management, Configuration Management, Service Level Management and Availability  Management. · Problem Identification and Recording ­ Parameters defining the problem are  established, such as recurring incident symptoms or service degradation threatening  SLAs. Problem characteristics are recorded within the known problem database. Future  incidents that occur related to the individual problem may reference the problem record. · Classification and Allocation ­ Problems are classified by category, impact, urgency,  priority and status. · Investigation and Diagnosis ­ Data obtained from various processes and locations is  analyzed to diagnose the root cause of the problem. This activity may include re­creating  the problem or several iterative phases to deduce the actual root cause. Once the root  cause has been determined,  a workaround is developed if required. Once the Triumfant ITIL Primer  Page 7 
  • 8. diagnosis is complete, the problem is turned into a known error and is passed to the  Error Control portion of Problem Management.  Error Control:  The process of monitoring and providing solutions for known errors until they  are resolved. Error control contains the following activities: · Known Error Identification and Recording ­ Once the root cause has been  determined, the problem status changes to known error. A workaround is developed to  feed back to Incident Management to handle future incidents that occur before a final  solution is implemented. The known error definition can also be sent to the known error  database to be used in the matching process. · Solution Investigated ­ An assessment is performed on what will be required to resolve  the known error. This activity could consist of cross­functional teams to weigh different  solutions on various criteria including costs and benefits. · Defining Solution ­ A final solution is developed and a Request for Change (RFC) is  made via the Change Management Process. · Problem Evaluation and Review ­ After the change has been implemented, a Post  Implementation Review (PIR) is performed to evaluate the success of the solution and  associated changes. · Closure ­ Assuming the problem review declares the solution as successful, the  problem is finally closed. Triumfant ITIL Primer  Page 8 
  • 9. Change Management:  The goal of Change Management is to manage the process of change through standardized  methods and procedures, thereby limiting incidents related to change and improving day­to­day  operations.  Change Management Process  Throughout the Change Management process, illustrated in the figure above, various levels of  management may need to be involved for approval and planning depending on the type of  change. Typically there is a Change Manager, a Change Advisory Board (CAB), and an  emergency change committee. The following activities are performed for all non­standard  changes: · Request for Change (RFC) ­ Other ITIL processes, customers and IT personnel make  requests for modifications to the managed infrastructure. These changes are typically Triumfant ITIL Primer  Page 9 
  • 10. not considered Service Requests, as those are considered standard changes that do not  need to be individually addressed by Change Management. · Recording ­ Information relevant to the RFC is recorded that includes a change  identification number, relevant problem/known error, justification, description, change  date, request originator information, and what configuration items are to be changed. · Acceptance ­ RFCs are checked for valid information and either accepted or denied.  Typically the acceptance involves financial approval, technical approval and business  approval. · Classification ­ Priorities and categories are specified for RFCs. Priority specifies the  level of importance and category specifies the basis of impact and resources. · Planning ­ A change calendar, or Forward Schedule of Changes (FSC), details all  approved and planned changes. The CAB will meet to discuss the various  considerations surrounding the RFC, such as dependencies, conflicts with other  changes, impact to resources and other services, back­out plans, change window, etc. · Coordination ­ Change Management is responsible for the coordination of building,  testing and implementing the change. This is typically done in conjunction with the  Release Management process. · Evaluation ­ Results of non­standard changes should be evaluated to ensure that  objectives were met, users are satisfied, evaluate possible side effects, and confirm if  changes were within the projected budget. · Closure ­ After a successful evaluation, the RFC is closed.  Release Management:  The goal of Release Management, illustrated in the figure below, is to ensure quality within the  production environment through a managed rollout of new versions within the managed  infrastructure. Change Management is focused on the coordination and planning of changes  while Release Management is focused on the actual implementation of those changes.  Release Management also works with Configuration Management to ensure that the CMDB is  kept up to date and that all new software releases are stored in the Definitive Software Library  (DSL). All spare hardware components and assemblies are stored within the Definitive  Hardware Store (DHS). Triumfant ITIL Primer  Page 10 
  • 11. Release Management Process  The following activities are part of Release Management: · Policy and Planning ­ A document, called the Release Policy, is developed by the  Release Manager and defines how and when releases are configured. Prior to planning  a release, information must be gathered about various aspects of the release, such as  product life cycle, description of relevant IT service and service levels, authorization for  relative RFCs, etc. Planning the release involves coordination, scheduling,  communication planning, definition of roles and responsibilities, development of back­out  and quality plans, and more. · Design, Building and Configuration ­ Standard and reusable procedures and  documentation should be used for designing, building and configuring releases.  Configuration items within the release may come from internal or external bodies. In  either case, laboratory­based development testing along with appropriate operational  documentation should be prerequisites before a release is considered available for  implementation. · Testing and Acceptance ­ Lack of testing is the most common cause for unsuccessful  changes and releases. Releases should undergo functional, operational, performance  and integration testing by the appropriate personnel. Testing should include back­out  plans. Acceptance should be performed for each step of the release process and be  submitted to Change Management for approval. Once approved, the release can be  rolled out and the relevant configuration changes can be integrated within the CMDB  (see Configuration Management). Triumfant ITIL Primer  Page 11 
  • 12. · Rollout Planning ­ Includes a detailed timetable of release events including staff  responsibilities and action items, documentation and purchasing plans for required  hardware and software. · Communication ­ Personnel, typically the Service Desk or Customer Relations,  communicate the planned changes to users and the expected service impact. Training  sessions may be required to aid users with the release. · Distribution and Installation ­ Involves the distribution of software and supporting  hardware identified and approved in the previous activities.  Configuration Management:  The goal of Configuration Management is to manage the value of IT services by maintaining a  logical model of the IT infrastructure and services, and by providing information about them to  other processes. This is accomplished by identifying, monitoring, controlling and providing  information about configuration items and their versions. Configuration Management aims to  have reliable records of IT components and services, while also providing accurate  documentation.  Configuration Management, illustrated in the figure below, identifies the various components of  IT infrastructure as Configuration Items (CIs). All of the information regarding CIs is held within  the Configuration Management Database (CMDB).  Configuration Management Process Triumfant ITIL Primer  Page 12
  • 13. The following are activities within the Configuration Management Process: · Planning ­ Defining the scope, purpose, objectives, priorities, policies and procedures of  the Configuration Management process. · Identification ­ Defining and maintaining configuration structures for CIs including  naming conventions, version numbers, physical components, interrelationships and  documentation. This activity involves allocating identifiers and version numbers, and  entering data into the CMDB. · Control ­ Ensures the authorization and recording of CI changes, such as additions,  deletions, relationship changes, etc. · Status Monitoring ­ Tracks life cycle states of CIs. · Verification ­ Auditing used to validate the physical existence of CIs and that the  corresponding entries in the CMDB are accurate. Triumfant ITIL Primer  Page 13 

×