ITIL version 2: Foundation Training


Published on

Slideset for ITIL Foundation Training

Published in: Business, Education

ITIL version 2: Foundation Training

  2. 2. Course objectives <ul><li>See value of IT Service Management </li></ul><ul><li>Increase overall understanding of processes and their relationships </li></ul><ul><li>Gain understanding of ITIL concepts </li></ul><ul><li>Provide a common Service Management vocabulary </li></ul>
  3. 3. Agenda - I <ul><li>Introduction </li></ul><ul><li>Configuration Management </li></ul><ul><li>Service Desk </li></ul><ul><li>Incident Management </li></ul><ul><li>Problem Management </li></ul><ul><li>Change Management </li></ul><ul><li>Release Management </li></ul>
  4. 4. Agenda - II <ul><li>Capacity Management </li></ul><ul><li>Availability Management </li></ul><ul><li>IT Service Continuity Management </li></ul><ul><li>Financial Management for IT Services </li></ul><ul><li>Service Level Management </li></ul><ul><li>Exam Preparation </li></ul>
  5. 5. Today’s reality <ul><li>Organizations increasingly dependent on IT </li></ul><ul><li>Higher visibility of failures </li></ul><ul><li>More specific requirements </li></ul><ul><li>Increased complexity of IT-infrastructure </li></ul><ul><li>Pressure to initiate (fair) charging for IT-services </li></ul><ul><li>Increasing globalization more competition </li></ul>
  6. 6. What is IT Service Management? <ul><li>IT Service Management is t he understanding that IT should focus on (internal and external) customer requirements by promoting a service-oriented approach. </li></ul>business satisfaction quality services at justifiable costs
  7. 7. Benefits of IT Service Management <ul><li>Higher reliability of IT-service provision </li></ul><ul><li>More detailed specification of requirements </li></ul><ul><li>Better understanding of true capabilities of IT </li></ul><ul><li>Information available to support decision making </li></ul><ul><li>Greater control of IT-assets </li></ul>
  8. 8. What is ITIL? <ul><li>I nformation T echnology I nfrastructure L ibrary </li></ul><ul><li>ITIL is a means to help IT-organizations provide customer focused IT-services using an approach based upon processes to meet agreed and specified levels of service. </li></ul>
  9. 9. ITIL History <ul><li>Developed in the 1980's, ITIL has become the world- </li></ul><ul><li>wide de facto standard in Service Management. Starting </li></ul><ul><li>as a guide for UK government, it has proved to be useful </li></ul><ul><li>to organizations in all sectors through its adoption by </li></ul><ul><li>many Service Management companies as the basis for </li></ul><ul><li>consultancy, education and software tools support. </li></ul>
  10. 10. ITIL ethos <ul><li>Collection of industry best practices </li></ul><ul><li>World-wide de-facto standard </li></ul><ul><li>Data owned by OGC but content is public domain </li></ul><ul><li>International recognized certifications </li></ul><ul><li>Continuous improvement via itSMF </li></ul>
  11. 11. <ul><li>40 Multiple choice questions </li></ul><ul><li>closed book examination </li></ul><ul><li>60 minutes allocated time </li></ul><ul><li>26 correct answers to pass (65%) </li></ul><ul><li>The ITIL Foundation certificate is a prerequisite for further </li></ul><ul><li>IT Service Management courses. </li></ul>Recognized examination
  12. 12. ITIL Publication Framework The Business The Business Perspective The Technology IT Service Management Planning to implement IT Service Management Application Management ICT Infrastructure Management IT Service Delivery IT Service Support IT Security Management
  13. 13. Support and Delivery processes Service Su pp ort Service Desk Incident Management Problem Management Configuration Management Change Management Release Management Service Deliver y Capacity Management Availability Management IT Service Continuity Management Financial Management for IT Services Service Level Management
  14. 14. <ul><li>Perform iterative activities to reach predefined and specified goals </li></ul><ul><li>Not restricted to departments or teams </li></ul><ul><li>Generate documentation to compare and evaluate the results with the objectives </li></ul><ul><li>Requires understanding of the business throughout the IT-organization </li></ul>Process Management
  15. 15. Processes in theory Input Output Process Activities Responsibilities Roles Quality parameters Key Performance Indicators Resources Competencies Process goal Process owner Materials, Machines, Information, Labour. Services, Products, Information, Reports
  16. 16. Processes in real life Process IT Department email Service Unit Service Desk Technical Support Network Management Application Support Application Development Application Maintenance
  17. 17. Some best practices <ul><li>Pay sufficient attention to (allocation of) roles </li></ul><ul><li>Define tasks, responsibilities and authorities </li></ul><ul><li>Ensure inputs and outputs are established </li></ul><ul><li>Avoid process by-passing </li></ul><ul><li>Do not reinvent the wheel </li></ul><ul><li>Choose appropriate Project Management methodology </li></ul><ul><li>DO NOT FORGET COMMUNICATION!!! </li></ul>
  18. 18. ITIL & IT-Governance <ul><li>British Standard Institute (BS15000 & BS7799) </li></ul><ul><li>Deming (Plan, Do, Check, Act) </li></ul><ul><li>Business Continuity Management </li></ul><ul><li>Project Management </li></ul><ul><li>Sarbanes Oxley </li></ul><ul><li>ISO </li></ul><ul><li>COBIT </li></ul><ul><li>CMM </li></ul><ul><li>Six Sigma </li></ul><ul><ul><li>ITIL goes mainstream in 2005 and widespread adoption will continue through 2008… </li></ul></ul><ul><ul><li>(source: Forrester Research) </li></ul></ul>
  19. 19. Configuration Management
  20. 20. Configuration Management - mission <ul><li>To provide a logical model of the IT-infrastructure and/or IT-services by identifying, controlling, maintaining and verifying the components used. </li></ul>
  21. 21. Some responsibilities <ul><li>Account for all IT-assets and configurations </li></ul><ul><li>Provide accurate information on configurations to support all the other Service Management processes </li></ul><ul><li>Provide a sound basis for Incident, Problem, Change and Release Management </li></ul><ul><li>Verify the configuration records against the actual IT-infrastructure and correct any exceptions </li></ul>
  22. 22. Definitions <ul><li>Components within the IT-infrastructure are referred to as Configuration Items (CI’s) </li></ul><ul><li>Details of/on CI’s are stored in the Configuration Management DataBase (CMDB) from which queries about the IT-infrastructure can be answered; this data can be stored in multiple locations; e.g. electronic (relational) databases, books </li></ul>
  23. 23. Process activities Planning Identification Control Status Accounting Verification & Audits
  24. 24. Planning <ul><li>During the initial planning phase the following should be defined: </li></ul><ul><ul><li>Purpose, scope and objectives </li></ul></ul><ul><ul><li>Related policies and standards </li></ul></ul><ul><ul><li>Roles and responsibilities </li></ul></ul><ul><ul><li>CI naming conventions </li></ul></ul><ul><ul><li>Procedures </li></ul></ul><ul><ul><li>CMDB design, including scope and key interfaces. </li></ul></ul>
  25. 25. What will be in the Scope? <ul><li>Hardware </li></ul><ul><li>Software </li></ul><ul><li>Documentation </li></ul><ul><li>Environment </li></ul><ul><li>Services </li></ul><ul><li>People? </li></ul>
  26. 26. A possible design of the CMDB
  27. 27. The right level of detail <ul><li>Ask yourself the following questions: </li></ul><ul><ul><li>Is the component still uniquely identifiable? </li></ul></ul><ul><ul><li>Is the component subject to change? </li></ul></ul><ul><ul><li>Is it still manageable? </li></ul></ul><ul><li>But most important: </li></ul><ul><li>DO YOU NEED THE INFORMATION </li></ul><ul><li>TO PROVIDE A SERVICE? </li></ul>
  28. 28. What data do we maintain? <ul><li>Characteristics of CI’s: </li></ul><ul><ul><li>Unique identifier (LPTP_0234, PRN_HP_CJ_02) </li></ul></ul><ul><ul><li>Category (type of hardware or software) </li></ul></ul><ul><ul><li>Status (ordered, archived, testing) </li></ul></ul><ul><ul><li>History (Incidents, Problems, Changes) </li></ul></ul><ul><ul><li>Attributes (supplier, price, owner, location) </li></ul></ul><ul><ul><li>Relationships !!! (is connected to, part of..) </li></ul></ul>
  29. 29. Identification <ul><li>The Identification activity addresses: </li></ul><ul><ul><li>Configuration structures and the selection of CI’s </li></ul></ul><ul><ul><li>CI types and life-cycles </li></ul></ul><ul><ul><li>CI relationships </li></ul></ul><ul><ul><li>Identification of software and document libraries </li></ul></ul><ul><ul><li>Identification of configuration baselines </li></ul></ul><ul><ul><li>Naming conventions </li></ul></ul><ul><ul><li>Labelling CI’s. </li></ul></ul>
  30. 30. The identifier of a CI <ul><li>The identifier of a CI should be: </li></ul><ul><ul><li>Unique </li></ul></ul><ul><ul><li>Taking existing references within the organization into account </li></ul></ul><ul><ul><li>Clearly visible </li></ul></ul><ul><ul><li>Ideally short and meaningful. </li></ul></ul>
  31. 31. Configuration Baselines <ul><li>A Configuration Baseline is the configuration of a product or system established at a specific point in time, which captures both the structure and details of that product or system, and enables that product or system to be rebuilt at a later date. </li></ul><ul><li>Configuration baselines and approved, implemented Changes to those baselines should together constitute the currently approved configuration. </li></ul>
  32. 32. Control <ul><li>The Control activity organizes: </li></ul><ul><ul><li>Registration of new CI’s and versions </li></ul></ul><ul><ul><li>Updating of CI records </li></ul></ul><ul><ul><li>Archiving of CI’s and their associated records </li></ul></ul><ul><ul><li>Protection of the integrity of configurations </li></ul></ul><ul><ul><li>Updating of CMDB after periodic checking. </li></ul></ul><ul><li>To enable full control over your CI’s, updating of records must only be executed with proper approval of Change Management! </li></ul>
  33. 33. Status Accounting <ul><li>Status reports should be produced on a regular basis, listing, for all CI’s under control, their current version and history. </li></ul><ul><li>Status Accounting reports can be used to establish Baselines and enables changes between Baselines and Releases to be traceable. </li></ul>
  34. 34. Verification & Audit <ul><li>Before implementation into the live environment, new Releases, builds, equipment and standards should be verified against the contracted or specified requirements. </li></ul><ul><li>Physical configuration audits should be carried out to verify that the 'as-built' configuration of a CI conforms to its 'as-planned' configuration and its associated documents. </li></ul>
  35. 35. Some best practices <ul><li>Address tool selection as early on as possible in the planning cycle </li></ul><ul><li>Make use of discovery tools and/or inventory systems </li></ul><ul><li>Ensure no-one bypasses Change Management </li></ul><ul><li>“ Maximize control with a minimum of records&quot; </li></ul>
  36. 36. Service Desk
  37. 37. Service Desk - mission <ul><li>To minimize disruptions to the business, due to failures in the provision of IT-services, by detecting, recording and coordinating the activities required to restore these services. </li></ul>
  38. 38. Some responsibilities <ul><li>Act as the Single Point of Contact (SPoC) for users of IT </li></ul><ul><li>Restore the service whenever possible </li></ul><ul><li>Maximize service availability </li></ul><ul><li>Manage ALL requests for support to a closure </li></ul><ul><li>Be aware of the needs and requirements of the Customer(s) </li></ul>
  39. 39. Single Point of Contact (SPoC) <ul><li>Many organizations have implemented a central point of contact for handling IT-issues. This function or department is known under several names but ITIL prefers the term Service Desk. A SPOC is not only a central point for communication but also for the gathering and distribution of information. </li></ul>Call Centre Service Desk Help Desk
  40. 40. Different ways to organize <ul><li>Call Centre : main emphasis on professionally handling large call volumes of telephone-based communication </li></ul><ul><li>Help Desk : primary purpose is to manage, co-ordinate and resolve failures as quickly as possible and to ensure that nothing is lost, forgotten or ignored </li></ul><ul><li>Service Desk : extends the range of services, allowing business processes to be integrated into the Service Management infrastructure </li></ul>
  41. 41. Some characteristics <ul><li>Single Point of Contact (SPoC) </li></ul><ul><li>Log of all reported issues, numbered and time-stamped </li></ul><ul><li>Use of diagnostic scripts and other aids </li></ul><ul><li>Automatic escalation procedures </li></ul><ul><li>Communication with support staff (2 nd & 3 rd level) </li></ul><ul><li>Interface to SLA’s </li></ul><ul><li>Regular progress reporting </li></ul>
  42. 42. Service Desk implementation <ul><li>Staff – correct numbers, profile, skills </li></ul><ul><li>Define effectiveness metrics (KPI’s) </li></ul><ul><li>Select a suitable structure: </li></ul><ul><ul><li>Local Service Desk </li></ul></ul><ul><ul><li>Central Service Desk </li></ul></ul><ul><ul><li>Virtual Service Desk. </li></ul></ul>
  43. 43. Function or process <ul><li>Some activities of the Service Support and Service Delivery processes are carried out at the Service Desk </li></ul><ul><li>The management of a Service Desk is more a people issue than a process </li></ul><ul><li>In many organizations, Service Desks are separate functional entities or departments </li></ul><ul><li>For these reasons, </li></ul><ul><li>ITIL calls the Service Desk a FUNCTION </li></ul>
  44. 44. Additional Information <ul><li>According to Genesys (manufacturer of software) 84% of people that contacted a Service Desk had a negative experience, 56% therefore changed supplier </li></ul><ul><li>Service seems to be twice as important as a good product </li></ul><ul><li>More information can be found at: </li></ul>
  45. 45. Incident Management
  46. 46. Incident Management - mission <ul><li>To restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring the best possible levels of service. </li></ul>
  47. 47. <ul><li>Ensure optimal use of resources to support the organization during service failures </li></ul><ul><li>Provide effective communication on the progress of reported failures with all stakeholders </li></ul>Some responsibilities
  48. 48. Contacting the Service Desk <ul><li>I can no longer send or receive emails! </li></ul><ul><li>How do I create a macro in Word? </li></ul><ul><li>What is the status of my reported ‘problem’? </li></ul><ul><li>I need a new laptop </li></ul><ul><li>The printer does not work </li></ul><ul><li>I forgot my password </li></ul><ul><li>I already reported this, three times this week! </li></ul><ul><li>The coffee machine seems to be malfunctioning </li></ul><ul><li>... </li></ul>What are the real Incidents?
  49. 49. <ul><li>An Incident is any event which is not part of the standard operation of a service and which causes, or may cause , an interruption to, or a reduction in, the quality of that service. </li></ul>What is an Incident?
  50. 50. So the Incidents are … <ul><li>I can no longer send or receive emails! </li></ul><ul><li>How do I create a macro in Word? </li></ul><ul><li>What is the status of my reported ‘problem’? </li></ul><ul><li>I need a new laptop </li></ul><ul><li>The printer does not work </li></ul><ul><li>I forgot my password </li></ul><ul><li>I already reported this, three times this week! </li></ul><ul><li>The coffee machine seems to be malfunctioning </li></ul><ul><li>... </li></ul>The others are Service Requests
  51. 51. More definitions <ul><li>A Service Request is every Incident not being a failure in </li></ul><ul><li>the IT-infrastructure </li></ul><ul><li>A Request for Change is used to record details of a </li></ul><ul><li>Change to any component (CI) within the IT-infrastructure </li></ul><ul><li>A work-around is a method of solving the Incident, but it </li></ul><ul><li>does NOT prevent it. In a way it by-passes (circumvents) </li></ul><ul><li>an Incident (e.g. CTRL-ALT-DEL) </li></ul><ul><li>A temporary fix prevents the occurring of further </li></ul><ul><li>Incidents until a structural solution has been found </li></ul>
  52. 52. Process activities Detection & recording Classification & Initial support Investigation & Diagnosis Resolution & Recovery Closure Service Request Procedure Service Request ? Monitoring & Tracking
  53. 53. Classification <ul><li>Typically classification consists out of: </li></ul><ul><ul><li>Categorization </li></ul></ul><ul><ul><li>Prioritizing </li></ul></ul><ul><ul><li>Matching. </li></ul></ul><ul><li>Classification is used to: </li></ul><ul><ul><li>Specify the service with which the Incident is related </li></ul></ul><ul><ul><li>Associate with an SLA where appropriate </li></ul></ul><ul><ul><li>Select the best specialist or group to handle the Incident </li></ul></ul><ul><ul><li>Identify the priority based upon the business impact and urgency </li></ul></ul><ul><ul><li>Define what information should be checked or asked for. </li></ul></ul>
  54. 54. Impact + Urgency = Priority <ul><li>Impact: </li></ul><ul><li>Affect on the business </li></ul><ul><li>Defined in the SLA </li></ul><ul><li>Same codes used throughout the organization. </li></ul><ul><li>Urgency: </li></ul><ul><li>Speed needed to resolve Incident </li></ul><ul><li>Extent to which it can bear delay. </li></ul><ul><li>Priority: </li></ul><ul><li>Sequences reported issues </li></ul><ul><li>Not assigned by the User </li></ul><ul><li>Not decided by the Service Desk. </li></ul>
  55. 55. Priority coding - example Priority code Description Target resolution time 1 Critical 1 hour 2 High 8 hours 3 Medium 24 hours 4 Low 48 hours 5 Planning Planned Incident Priority Impact High Medium Low Urgency High 1 2 3 Medium 2 3 4 Low 3 4 5
  56. 56. Incident Matching <ul><li>Matching is the activity whereby the Incident details are </li></ul><ul><li>compared to knowledge that is already present in the </li></ul><ul><li>organization. Successful matching could give access to </li></ul><ul><li>proven resolution actions, and could therefore expedite the </li></ul><ul><li>resolution process. </li></ul>
  57. 57. Matching - example
  58. 58. Escalation paths Service Request Procedure Detect, Record & Classifiction Service Request? Initial Support Resolved? Resolution, Recovery Investigation Diagnose Resolved? Resolution, Recovery Investigation Diagnose Resolved? Resolution, Recovery Incident Closure Yes No Yes No Yes No Et cetera Third Level Second Level First Level
  59. 59. Escalation <ul><li>Transferring an Incident from first-level to second-level support groups or third-level support groups is called functional escalation and primarily takes place when more knowledge or expertise is required to restore the service. </li></ul><ul><li>An Incident is hierarchically escalated when a manager is informed about the likelihood of the Incident not being resolved in time or to customer satisfaction. Hierarchical escalation can take place at any moment during the process. </li></ul>
  60. 60. When to close an Incident? <ul><li>After submitting RfC? </li></ul><ul><li>When a Change is implemented? </li></ul><ul><li>Does a work-around close the Incident? </li></ul><ul><li>When you defined a Problem? </li></ul><ul><li>After a certain amount of time? </li></ul><ul><li>When you await a third-party response? </li></ul>Ensure the Customer is satisfied with the chosen resolution!
  61. 61. Some best practices <ul><li>Create knowledge databases and make them ‘easily’ accessible </li></ul><ul><li>Use tools whenever appropriate but pay extra attention to the design of user-interfaces </li></ul><ul><li>Establish interfaces and communication with other processes </li></ul><ul><li>Pay attention to categorization </li></ul><ul><li>Many activities take place at the Service Desk; make sure the staff is properly trained </li></ul>
  62. 62. Problem Management
  63. 63. Problem Management - mission <ul><li>To minimize the adverse impact of Incidents and Problems on the business that are caused by failures within the IT-infrastructure, and to prevent the recurrence of such failures. </li></ul>
  64. 64. Some responsibilities <ul><li>Ensure Problems are identified and resolved </li></ul><ul><li>Minimize the impact of Problems and Incidents on the IT-service provision </li></ul><ul><li>Ensure that the right level and number of resources are resolving specific Problems </li></ul><ul><li>Provide information to Incident Management and the Service Desk </li></ul>
  65. 65. When is a Problem a Problem? <ul><li>Many criteria can be used to define a Problem: </li></ul><ul><ul><li># of related Incidents </li></ul></ul><ul><ul><li>Incident closed via workaround </li></ul></ul><ul><ul><li>Major Incidents </li></ul></ul><ul><ul><li>Information from third-parties </li></ul></ul><ul><ul><li>An engineer with an excellent idea </li></ul></ul><ul><ul><li>…… </li></ul></ul>
  66. 66. Definitions <ul><li>Problem : The unknown root cause of one or more Incidents or potential Incidents </li></ul><ul><li>Error: A condition that exists after the successful diagnosis of the root cause of a Problem when it is confirmed which CI is at fault </li></ul><ul><li>Known Error: Error + solution and/or workaround has been found </li></ul><ul><li>The terms Error and Known Error are very often interchanged in everyday situations. </li></ul>
  67. 67. Problem Control Problem identification and recording Problem classification Problem investigation and diagnosis Root cause analysis Tracking and monitoring of Problems Incident database, 3 rd party information, etc. Error (to Error-Control)
  68. 68. Error Control Error identification and recording Error assessment Error resolution Recording (KE) Tracking and monitoring of Errors Information from Problem Control Review results and close the associated records RfC Change successfully implemented
  69. 69. Problems, Errors and Known Errors RfC Incident Control Problem Control Solved? Solved Closed Closed User Closed PIR Error Control Work around Incident Management Problem Management Change Management Problem Incident Error Known Error Change KEDB
  70. 70. Known Error DataBase <ul><li>Sometimes a system might be allowed to be released into the live environment even though (Known) Errors have been detected during testing. </li></ul><ul><li>Problem Management needs to ensure any such (Known) Errors, and any resolutions, are recorded in the Known Error Database. </li></ul>
  71. 71. Proactive Problem Management <ul><li>Proactive Problem Management covers the activities aimed at identifying and resolving failures before they actually occur. These activities are: </li></ul><ul><ul><li>Trend analysis </li></ul></ul><ul><ul><li>Targeting support/preventative action(s) </li></ul></ul><ul><ul><li>Feed-back of information to relevant people. </li></ul></ul>
  72. 72. Incident and Problem Management <ul><li>Often, the Incident Management registration is the basis for the definition of Problems. </li></ul><ul><li>Also, information from Problem Management should be made available for Incident Matching. </li></ul><ul><li>However, keep in mind: </li></ul><ul><ul><li>Objectives are different </li></ul></ul><ul><ul><li>Different skills/expertise required </li></ul></ul><ul><ul><li>Time is less of an issue within Problem Management </li></ul></ul><ul><ul><li>Activities carried out are different. </li></ul></ul>
  73. 73. Fire fighting or … ? Do we want our fire fighters to stop fighting fire and start a discussion on the origins of that fire?
  74. 74. Some best practices <ul><li>Start with reactive Problem Management </li></ul><ul><li>Try and separate Incident Management from Problem Management </li></ul><ul><li>Make use of tools to detect (possible) trends </li></ul><ul><li>Ensure a sound interface with Incident and Change Management exists </li></ul>
  75. 75. Change Management
  76. 76. Change Management - mission <ul><li>To manage all Changes that could impact the ability to deliver (quality) IT-services; through a single, centralized process of approval, scheduling and control to ensure that the IT-infrastructure stays aligned to business requirements. </li></ul>
  77. 77. Some responsibilities <ul><li>Change Management is responsible for managing Change </li></ul><ul><li>processes involving: </li></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>Communications equipment and software </li></ul></ul><ul><ul><li>System software </li></ul></ul><ul><ul><li>‘ Live' applications software </li></ul></ul><ul><ul><li>All documentation and procedures associated with the day-to-day operation, support and maintenance of live systems. </li></ul></ul>
  78. 78. Definitions <ul><li>A Change is any addition, modification or removal of one or more CI’s </li></ul><ul><li>A Request for Change (RfC) is an electronic or paper-based form used to record details of a request for a change to any CI </li></ul><ul><li>The Forward Schedule of Changes (FSC) is a schedule that contains an overall view of all approved Changes and their status in a special, carefully predefined order </li></ul><ul><li>The Change Advisory Board (CAB) is the meeting where (submitted) Changes are discussed </li></ul>
  79. 79. Change & Project Management Registration and classification Change Management Project Management Approval Authorization and Implementation Evaluation (PIR) Monitoring and Planning Building Testing Implementation Change Monitoring
  80. 80. The Request for Change (RfC) The RfC should detail as many aspects of the Change as possible. Impact Resource estimation Business justification Cost … Back-out Deadline Originator CI’s RfC
  81. 81. Priority of Changes <ul><li>Urgent - Change necessary NOW (approval via CAB Emergency Committee) </li></ul><ul><li>High - Change needed as soon as possible (a CAB needs to be assembled ASAP) </li></ul><ul><li>Medium - Change can bear delay until next regular CAB meeting </li></ul><ul><li>Low - Change leads to minor improvements (can be postponed until further notice) </li></ul>
  82. 82. Category of Changes <ul><li>Category 0 (standard Change) - the Change is executed without prior contact (automatic approval) </li></ul><ul><li>Category 1 (little or no impact) - the Change Manager authorizes this RfC </li></ul><ul><li>Category 2 (significant impact) - the RfC must be discussed in the CAB where the Change Manager requests advice on authorization and planning </li></ul><ul><li>Category 3 (major impact) - considerable manpower and/or resources required; senior management should be represented in the CAB </li></ul>
  83. 83. The Change Advisory Board (CAB) <ul><li>To ensure proper representation, members of the CAB should include representatives from the following areas: </li></ul><ul><ul><li>Customers affected by the Change </li></ul></ul><ul><ul><li>Representatives from all other Service Management disciplines </li></ul></ul><ul><ul><li>Application Development Teams (e.g. project leader) </li></ul></ul><ul><ul><li>Senior Users, or their representatives. </li></ul></ul>
  84. 84. The CAB agenda <ul><li>A standard CAB agenda includes a review of: </li></ul><ul><ul><li>Failed or backed-out Changes </li></ul></ul><ul><ul><li>Changes applied without reference to the ‘regular’ CAB by Incident Management (e.g. CAB/EC approved Changes) </li></ul></ul><ul><ul><li>RfC’s to be assessed by CAB </li></ul></ul><ul><ul><li>Status of RfC’s that have been assessed by CAB already </li></ul></ul><ul><ul><li>Change reviews (PIR) </li></ul></ul><ul><ul><li>Change Management process. </li></ul></ul>
  85. 85. CAB agenda - example
  86. 86. Approval processes <ul><li>There are three principal approval processes: </li></ul><ul><ul><li>Financial approval (indicated costs are within budgetary limits or </li></ul></ul><ul><ul><li>cost-benefit criteria are met) </li></ul></ul><ul><ul><li>Technical approval (assurance that the Change is feasible and sensible and can be performed without serious interruptions to the business) </li></ul></ul><ul><ul><li>Customer approval (to ensure that business managers are satisfied with the proposals and accept the impact (if any) on their operations). </li></ul></ul>
  87. 87. Some best practices <ul><li>Be prepared for dealing with Urgent Changes </li></ul><ul><li>Integrate with Configuration and Release Management </li></ul><ul><li>Ensure management commitment is present and let them set the example </li></ul><ul><li>Choose appropriate Project Management methodologies (e.g. PMBOK, PRINCE2) </li></ul>
  88. 88. Release Management
  89. 89. Release Management - mission <ul><li>To take a holistic view of a Change to an IT-service and to ensure that all aspects of a Release, both technical and non-technical, are considered. </li></ul>
  90. 90. Some responsibilities <ul><li>Communicate Changes in CI’s to Configuration Management </li></ul><ul><li>Physical distribution and installation of Changes </li></ul><ul><li>Ensuring that only correctly released, tested and authorized CI’s are used </li></ul><ul><li>Physical storage of software and hardware components </li></ul>
  91. 91. What is a Release? <ul><li>A Release consists of new or changed software and/or </li></ul><ul><li>hardware required to implement approved Changes. </li></ul><ul><li>Releases are divided into: </li></ul><ul><ul><li>Minor software Releases and hardware upgrades </li></ul></ul><ul><ul><li>Major software Releases and hardware upgrades </li></ul></ul><ul><ul><li>Emergency software and hardware fixes. </li></ul></ul>
  92. 92. The holistic approach
  93. 93. The Release Policy <ul><li>A Release Policy should specify: </li></ul><ul><ul><li>Release naming and numbering conventions </li></ul></ul><ul><ul><li>A definition of major and minor Releases, plus a policy on issuing emergency Releases </li></ul></ul><ul><ul><li>Direction on the frequency of Releases </li></ul></ul><ul><ul><li>Expected deliverables for Releases (e.g. installation instructions and Release notes) </li></ul></ul><ul><ul><li>Guidance as to how and where Releases should be documented (e.g. which tool to use and how) </li></ul></ul><ul><ul><li>The policy on the production of back-out/roll-back plans. </li></ul></ul>
  94. 94. Secure Storage Areas <ul><li>The Definitive Software Library (DSL) is a term used to describe a secure repository in which the authorized versions of original and approved software CI’s are stored and protected. </li></ul><ul><li>The Definitive Hardware Storage (DHS) is a term used to describe an area set aside for the secure storage of definitive hardware spares. For many organizations, this often consists out of contracts with their suppliers. </li></ul>
  95. 95. DSL, DHS and the CMDB DSL/DHS Physical CI’s CMDB Logical CI’s Release Record Build new Releases Test new Releases Distribute new Releases to live locations Implement new Releases
  96. 96. Some best practices <ul><li>Don’t separate Development and Operations </li></ul><ul><li>Seek alignment to Change and Configuration Management procedures </li></ul><ul><li>Create test environments that represent the live hardware and software environments as closely as possible </li></ul><ul><li>Take back-out plans seriously, even when history shows they are not used </li></ul><ul><li>Allocate sufficient resources to communication, testing, documentation and training </li></ul>
  97. 97. Capacity Management
  98. 98. Capacity Management - mission <ul><li>To ensure that sufficient and cost justifiable capacity of IT (resources) is in place and that it is matched to the current and future identified needs of the business. </li></ul>
  99. 99. Some responsibilities <ul><li>Monitor performance and throughput of IT-services </li></ul><ul><li>Initiate tuning activities to make the most efficient use of existing resources </li></ul><ul><li>Understand the demands currently being made for IT-resources and produce forecasts for future requirements </li></ul>
  100. 100. Process activities Business Capacity Management (BCM) Service Capacity Management (SCM) Resource Capacity Management (RCM) CDB Capacity Plan production The Capacity Plan Application sizing Demand Management Modelling
  101. 101. Predicting the Future <ul><li>Modelling </li></ul><ul><li>= </li></ul><ul><li>predicting behaviour under a given volume/variety of work </li></ul><ul><li>Estimation </li></ul><ul><li>Trend analysis </li></ul><ul><li>Analytical modelling </li></ul><ul><li>Simulation modelling </li></ul><ul><li>Benchmarking </li></ul>Costs Accuracy
  102. 102. Application Sizing <ul><li>Application Sizing is the prediction of the consequences of new and/or changed applications on: </li></ul><ul><ul><li>Service Levels </li></ul></ul><ul><ul><li>Resources </li></ul></ul><ul><ul><li>Costs </li></ul></ul><ul><ul><li>Existing applications. </li></ul></ul>
  103. 103. The Capacity DataBase <ul><li>Capacity Management collects data from a variety of (distributed) hardware platforms and software applications. </li></ul><ul><li>Data stored in a CDB could include: </li></ul><ul><ul><li>Service data from SLA’s </li></ul></ul><ul><ul><li>Business data from business plans </li></ul></ul><ul><ul><li>Technical data </li></ul></ul><ul><ul><li>Financial data </li></ul></ul><ul><ul><li>Utilization data. </li></ul></ul>
  104. 104. The Capacity Plan <ul><li>The Capacity Plan documents the current levels of resource utilization and service performance, and forecasts the future requirements for resources that underpin the business activities. </li></ul>
  105. 105. Some best practices <ul><li>Create interfaces with Availability, Financial and Change Management </li></ul><ul><li>Do not rely too much on third-party statistics </li></ul><ul><li>Ensure business expertise is available, especially for forecasting purposes </li></ul><ul><li>Keep your overall Capacity Plan reviews and updates in line with budgetary cycles </li></ul>
  106. 106. Availability Management
  107. 107. Availability Management - mission <ul><li>To optimize the capability of the IT-infrastructure, services and supporting organization to deliver effective and sustained levels of availability that enable the business to satisfy its objectives. </li></ul>
  108. 108. Some responsibilities <ul><li>Determine requirements from the business </li></ul><ul><li>Formulate Availability and Recovery design criteria </li></ul><ul><li>Determine the Vital Business Functions </li></ul><ul><li>Define targets, monitoring and reporting for Availability, Reliability and Maintainability of CI’s </li></ul><ul><li>Produce and maintain an Availability Plan </li></ul>
  109. 109. Definitions <ul><li>Availability: The ability to perform a required function at a stated instant or over a stated period of time </li></ul><ul><li>Reliability: Freedom from operational failure </li></ul><ul><li>Maintainability: The ability of a CI to be retained in, or restored to, an operational state </li></ul><ul><li>Serviceability: The contractual arrangements made with third parties, to assure the availability, reliability and maintainability of CI’s under their care </li></ul><ul><li>Security: The Confidentiality , Integrity and Availability of CI’s </li></ul>
  110. 110. Resilience Server Network Host = 89.89% 98% 98% 97.5% Workstation 96% Server Network Host = 91.69% 99.96% 98% 97.5% Workstation 96% Host
  111. 111. The Extended Incident Lifecycle Incident Recover Diagnosis Incident Restore MTBF – Mean Time Between Failures (uptime) Response Time Detection Time MTBSI – Mean Time Between System Incidents (reliability) MTTR - Mean Time To Repair (downtime) Repair Detection Repair Time Recovery Time
  112. 112. The Availability plan <ul><li>The Availability Plan includes goals (targets), objectives and deliverables and should consider the wider issues of people, process, tools and techniques as well as having a focus on technological developments/innovations. </li></ul><ul><li>The Availability Plan is a ‘tactical’ plan aimed at improving the overall Availability of the IT-infrastructure to ensure that existing and future levels of Availability can be provided on a timely and cost effective basis. </li></ul>
  113. 113. Some best practices <ul><li>Integrate with IT Service Continuity Management </li></ul><ul><li>Understand costs of unavailability </li></ul><ul><li>Automate component downtime detection and data recording </li></ul><ul><li>Availability Plan is considered complementary to the Capacity Plan; both should therefore be in alignment </li></ul>
  114. 114. IT Service Continuity Management
  115. 115. Disasters are a fact of life <ul><li>After the San Francisco Earthquake, 80 % of the organizations that could not recover within one week went bankrupt that same year (Gartner Group). </li></ul><ul><li>Disaster hits 7.5% of organizations world-wide each year (BCI). </li></ul>40% 30% 20% 10% fire theft human errors natural disasters virus hardware hacking environment software
  116. 116. ITSCM - mission <ul><li>To manage the risks of key IT-services failing by avoiding identified risks and by planning to recover key IT-services during a disaster, to support the continued functioning of the business to a specified level within agreed upon timescales. </li></ul>
  117. 117. Some responsibilities <ul><li>Reduce the vulnerability of the organization </li></ul><ul><li>Reduce identified risks and the threat of potential disasters </li></ul><ul><li>Plan for recovery of (business) processes and IT-services </li></ul><ul><li>Prevent loss of investor confidence </li></ul>
  118. 118. Process activities Requirements & Strategy Implementation Operational Management Initiation <ul><li>Initiate BCM </li></ul><ul><li>Business Impact Analysis </li></ul><ul><li>Risk Assessment </li></ul><ul><li>Business Continuity Strategy </li></ul><ul><li>Organization and Implementation Planning </li></ul><ul><li>Implement Stand-by Arrangements </li></ul><ul><li>Develop Recovery Plans </li></ul><ul><li>Develop Procedures </li></ul><ul><li>Initial Testing </li></ul><ul><li>Implement Risk Reduction Measures </li></ul><ul><li>Review and Audit </li></ul><ul><li>Testing </li></ul><ul><li>Education & Awareness </li></ul><ul><li>Change Management </li></ul><ul><li>Training </li></ul><ul><li>Assurance </li></ul>
  119. 119. Several continuity options <ul><li>The options: </li></ul><ul><ul><li>Do nothing </li></ul></ul><ul><ul><li>Manual workarounds </li></ul></ul><ul><ul><li>Reciprocal arrangements </li></ul></ul><ul><ul><li>Fortress Approach </li></ul></ul><ul><ul><li>Insurance </li></ul></ul><ul><ul><li>Mobile alternative </li></ul></ul><ul><ul><li>Immediate recovery – hot standby (<24 hrs) </li></ul></ul><ul><ul><li>Intermediate recovery – warm standby (24-72 hrs) </li></ul></ul><ul><ul><li>Gradual recovery – cold standby (>72 hrs). </li></ul></ul>
  120. 120. Testing the Plan <ul><li>Sit down and talk through Continuity Plan(s) with ALL those involved </li></ul><ul><li>Frequency of testing: </li></ul><ul><ul><li>Initially </li></ul></ul><ul><ul><li>Every 6-12 months </li></ul></ul><ul><ul><li>After every major Change to the Continuity Plan(s). </li></ul></ul>
  121. 121. Some best practices <ul><li>Ensure alignment to BCM and Availability Management </li></ul><ul><li>If it's not worth protecting, it's not worth doing </li></ul><ul><li>Test under realistic circumstances </li></ul><ul><li>Test regularly, keep documents up-to-date </li></ul><ul><li>Modifications through Change Management (CAB) </li></ul>
  122. 122. Financial Management for IT Services
  123. 123. Financial Management - mission <ul><li>To manage costs and to provide a sound financial basis for business decisions relating to IT by identifying and accounting for the costs of delivering services, and where appropriate by recovering costs in an equitable manner. </li></ul>
  124. 124. Some responsibilities <ul><li>Get an insight into the actual costs </li></ul><ul><li>Facilitate accurate budgeting </li></ul><ul><li>Provide a sound basis for business decisions (e.g. investments) </li></ul><ul><li>Contribute to balancing costs, capacity and requirements </li></ul><ul><li>Recover costs where and whenever required </li></ul>
  125. 125. Budgeting & Accounting <ul><li>Budgeting: </li></ul><ul><ul><li>The process of predicting and controlling the spending of money within the organization; budgeting consists of a periodic negotiation cycle to set budgets (annual) and the day-to-day monitoring of the current budgets. </li></ul></ul><ul><li>Accounting: </li></ul><ul><ul><li>The process that enables IT to fully account for the way money is spent which usually involves ledgers and should be overseen by someone trained in accountancy. </li></ul></ul>
  126. 126. Charging & Pricing Policies <ul><li>The set of processes required to bill customers for the services obtained by them, is referred to as Charging. However, to achieve this, Accounting MUST take place. </li></ul><ul><li>Pricing Methods: </li></ul><ul><ul><li>Cost Price </li></ul></ul><ul><ul><li>Cost Price Plus </li></ul></ul><ul><ul><li>Going Rate (Internal) </li></ul></ul><ul><ul><li>Market Rate (External) </li></ul></ul><ul><ul><li>Fixed Price. </li></ul></ul>
  127. 127. Getting an insight into Costs Cost elements <ul><li>Hardware </li></ul><ul><li>Software </li></ul><ul><li>People </li></ul><ul><li>Accommodation </li></ul><ul><li>External Service </li></ul><ul><li>Transfer </li></ul>Classification <ul><li>Fixed </li></ul><ul><li>Variable </li></ul><ul><li>Direct </li></ul><ul><li>Indirect </li></ul><ul><li>Capital </li></ul><ul><li>Operational </li></ul>Cost per <ul><li>Customer </li></ul><ul><li>IT-service </li></ul><ul><li>Activity </li></ul>
  128. 128. Some best practices <ul><li>Involve financial/accounting experts </li></ul><ul><li>Ensure interfaces with other ITIL processes exist </li></ul><ul><li>Use customer-based charging units </li></ul>
  129. 129. Service Level Management
  130. 130. Service Level Management - mission <ul><li>To maintain and improve the IT-service quality, through a constant cycle of agreeing, monitoring and reporting upon achievements and the instigation of actions to eradicate poor service. </li></ul>
  131. 131. Some responsibilities <ul><li>Have insight into the capabilities of IT </li></ul><ul><li>Understand the requirements of the Customer(s) </li></ul><ul><li>Catalog and quantify IT-services </li></ul><ul><li>Define (realistic) internal and external service targets </li></ul><ul><li>Ensure ongoing improvement of Service Levels </li></ul>
  132. 132. Elements of an SLA General Introduction Parties Signatures Service Description Reporting & reviewing Content Frequency Support Service Hours Support Change Procedures Escalation Delivery Availability Reliability Throughput Transaction response times Batch turnaround times Contingency Price Security!!!
  133. 133. Several documents User User User User IT Services IT Systems IT Systems Application support Network support Development Hardware Suppliers Software Suppliers Telecom Providers Customer Internal Suppliers External Suppliers Service Level Agreement IT Service Provider Operational Level Agreement Underpinning Contracts
  134. 134. The overall picture Service Catalogue Service Level Reports Service Level Agreements Service Level Requirements Specification Sheets Operational Level Agreements Underpinning Contracts Customer Supplier IT-organization Service Improvement Program Service Quality Plan
  135. 135. Process activities Plan Do Check Act <ul><li>Establish the function: </li></ul><ul><li>Initial planning </li></ul><ul><li>Plan for monitoring </li></ul><ul><li>Set initial service perception </li></ul><ul><li>Develop Underpinning Contracts </li></ul><ul><li>Develop Operational Level Agreements </li></ul><ul><li>Implement SLA’s: </li></ul><ul><li>Produce Service Catalogue </li></ul><ul><li>Plan SLA structure, draft SLA’s </li></ul><ul><li>Manage expectations </li></ul><ul><li>Seek agreement </li></ul><ul><li>Establish monitoring protocols </li></ul><ul><li>Review UC’s & OLA’s </li></ul><ul><li>Define reporting & review procedures </li></ul><ul><li>Manage the process: </li></ul><ul><li>Review satisfaction of SLA targets </li></ul><ul><li>Re-validate SLA targets & services addressed </li></ul><ul><li>Review periodically: </li></ul><ul><li>Monitor & report and hold service review meetings </li></ul><ul><li>Arrange Service Improvement Programs </li></ul><ul><li>Maintain SLA’s, associated OLA’s and UC’s </li></ul>
  136. 136. Some best practices <ul><li>Service Level Management is not just SLA’s; they are however a good starting point (provided metrics are available) </li></ul><ul><li>Ensure buy-in from all other Service Management processes </li></ul><ul><li>Signing contracts is not just sales </li></ul><ul><li>Make everybody in the organization aware of the targets specified in an SLA </li></ul>