Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

ITIL v3 Foundation Overview

34.357 Aufrufe

Veröffentlicht am

Guest Speaker Presentation on ITILv3 Foundation

ITIL v3 Foundation Overview

  1. 1. ITIL Overview Presented By: ADNAN ABBAS
  2. 2. Today’s Topics <ul><li>IT Organizations Current Challenges </li></ul><ul><li>IT Organization focus Today vs Tomorrow </li></ul><ul><li>Service & IT Service Management </li></ul><ul><li>ITIL </li></ul><ul><ul><li>History </li></ul></ul><ul><ul><li>Problem Definition </li></ul></ul><ul><ul><li>WHY ITIL </li></ul></ul><ul><ul><li>Ten Core processes of ITIL </li></ul></ul><ul><ul><li>Service Lifecycle </li></ul></ul><ul><li>Key Concepts to understand </li></ul><ul><li>CORE ITSM Components </li></ul>
  3. 3. <ul><li>Service Strategy </li></ul><ul><li>Service Design </li></ul><ul><li>Service Transition </li></ul><ul><li>Service Operation </li></ul><ul><li>Continual Service Improvement </li></ul><ul><li>Benefits of These Core Components </li></ul><ul><li>Change Management Process explained in ITIL </li></ul><ul><li>Helpdesk Management Process explained in ITIL </li></ul><ul><li>Benefits of ITSM </li></ul><ul><li>Conclusions and Recommendations </li></ul>Today’s Topics
  4. 4. IT Organization Current Challenges Business Challenges IT Responsibilities Minimizing risk in a dynamic business scenario Minimizing cost & time-to-market Improving ROI Increasing Business Performance IT enables the business to meet its goals Ensuring a stable & flexible IT environment Optimizing resources & costs Minimizing costs & complexity Adapting quickly to changing needs
  5. 5. The IT organization of the future will have a different focus
  6. 7. “ A service is a means of delivering value to customers by facilitating the outcomes that customers want to achieve without the ownership of specific costs and risks. ” What is an IT Service? An &quot;IT Service&quot; is a set of IT-related functions (HW & SW) User Web Server Application Server Database Server SERVICE
  7. 8. What is IT Service Management? IT Service Management is the totality of IT Service Provision, including the management of the infrastructure and the environment ENVIRONMENT Good IT Service Management ensures that Customer requirements; and expectations are met with consistency . IT Service IT Service IT Service IT Service INFRASTRUCTURE
  8. 9. IT Service Management Objectives <ul><li>To align IT Services with the current and future needs of the Business and its Customers </li></ul><ul><li>To improve the quality of the IT services delivered </li></ul><ul><li>To reduce the long term cost of service provision </li></ul>Needs Cost Quality
  9. 10. Key Elements Capacity Planning Configuration Management PARTNERS Tools / Technology Customer / End Users Service Manager / Team PEOPLE Production Acceptance Team Executive Sponsor Change Control Hardware Problem Management Software PROCESS PRODUCTS Project Manager / Team Suppliers / Outsourcers
  10. 11. ITIL : Information Technology Infrastructure Library <ul><li>Developed in late 1980s in the UK in response to growing dependence on IT </li></ul><ul><li>Now a public body of knowledge for Service Management best practices </li></ul><ul><li>Helps organizations improve service levels and reduce the cost of IT operations </li></ul><ul><li>A framework, defining ten interlocking processes for service support and service delivery </li></ul><ul><li>Also provides guidance on IT security, business management </li></ul><ul><li>The ten ITIL processes are described in two volumes: </li></ul><ul><ul><li>- Service Support focuses on management of essential operational processes </li></ul></ul><ul><ul><li>- Service Delivery on strategic management of the IT services </li></ul></ul>
  11. 12. The History behind ITIL 1980s 1990s 2000s ITIL Version 1 ITIL Version 2 British civil service 10+30 books 2+N books The Netherlands Rest of the world ITIL Version 3 2+N books
  12. 13. Defining the Problem
  13. 14. WHY ITIL? Because IT is critical to the Business
  14. 15. ITIL is process-oriented Processes Roles People Subtasks Leaders Middle mgmt Employees Areas of work ITIL Traditionally Top-down, controlling areas of responsibility Task-oriented, non-hierarchical
  15. 16. Ten core processes of ITIL (… and one function) Service Desk Incident mgmt Problem mgmt Config. mgmt Change mgmt Release mgmt Service Level mgmt Financial mgmt for IT-services Capacity mgmt IT Services Continuity mgmt Availability mgmt ITIL
  16. 17. What ITIL is not? <ul><li>A complete blue-print, but bricks and material from which you can build your own building depending on your needs. </li></ul><ul><li>A quick fix, but a set of processes that you have to build into the mind-set of your employees, and which must be continually updated and improved. </li></ul><ul><li>Something you buy, although you can buy help to implement it, the core of the work is changing your own organization and how it thinks and functions. </li></ul><ul><li>Another method of control, but a way of setting up your organizaton so that it works towards the goals without controlling management. </li></ul>
  17. 18. ITIL Service Lifecycle
  18. 19. Five Phases of ITILv3
  19. 20. ITIL: the process improvement program Typical program elements People <ul><li>Allocate roles and responsibilities (reorganization?) </li></ul><ul><li>Align skills to business needs </li></ul><ul><li>Organize ITIL training and motivation </li></ul><ul><li>Project/change management </li></ul>Processes <ul><li>Define processes and process tasks and document </li></ul><ul><li>Define process metrics/KPIs </li></ul><ul><li>Integrate process information </li></ul><ul><li>Initiate customer survey cycle </li></ul>Tools <ul><li>Process automation, process integration </li></ul><ul><li>Asset management repository </li></ul><ul><li>Configuration management database (CMDB) </li></ul><ul><li>Business service definition and mapping </li></ul>
  20. 21. “ Think of ITIL not as a destination, but as a vehicle you can use to help you travel more quickly and efficiently on your ongoing journey of continuously improving service levels ”
  21. 22. ITIL is a CATALYST for transforming IT. Traditionally IT has operated in functional silos with separate goals and objectives. But in Today’s environment, IT is changed with transforming itself into a service oriented culture, where cross functional teams are unified in the common pursuit of service excellence and business alignment.
  22. 23. ITIL is DESCRIPTIVE versus PRESCRIPTIVE ITIL describes what needs to be done to improve service, BUT It does not explain how to do it.
  23. 24. Key Concepts <ul><li>Configuration Management System (CMS) </li></ul><ul><ul><li>Tools and databases to manage IT service provider’s configuration data </li></ul></ul><ul><ul><li>Contains Configuration Management Database (CMDB) </li></ul></ul><ul><ul><ul><li>Records hardware, software, documentation and anything else important to IT provision </li></ul></ul></ul><ul><li>Release </li></ul><ul><ul><li>Collection of hardware, software, documentation, processes or other things require to implement one or more approved changes to IT Services </li></ul></ul>
  24. 25. Key Concepts <ul><li>Incident </li></ul><ul><ul><li>Unplanned interruption to an IT service or an unplanned reduction in its quality </li></ul></ul><ul><li>Work-around </li></ul><ul><ul><li>Reducing or eliminating the impact of an incident without resolving it </li></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Unknown underlying cause of one or more incidents </li></ul></ul>
  25. 26. Key Concepts Processes(s) : are structured sets of activities designed to achieve a specific objective. Function(s) : are self-contained subsets of an organization intended to accomplish specific tasks. They usually take the form of a team or group of people and the tools they use. “ Processes help organizations accomplish specific objectives often across multiple functional groups” whereas “ Functions add structure and stability to organization”
  26. 27. <ul><li>Roles: are defined collections of specific responsibilities and privileges. Roles may be held by individuals or teams. Individuals and teams may hold more than one role. ITIL® emphasizes a number of standard roles include, most importantly: </li></ul><ul><li>Service Owner -- Accountable for the overall design, performance, integration, improvement, and management of a single service . </li></ul><ul><li>Process Owner -- Accountable for the overall design, performance, integration, improvement, and management of a single process . </li></ul><ul><li>Service Manager -- Accountable for the development, performance, and improvement of all services in the environment. </li></ul><ul><li>Product Manager – Accountable for development, performance, and improvement of a group of related services . </li></ul>Key Concepts
  27. 28. More Roles <ul><li>Business Relationship Manager </li></ul><ul><li>Service Asset & Configuration </li></ul><ul><ul><li>Service Asset Manager </li></ul></ul><ul><ul><li>Service Knowledge Manager </li></ul></ul><ul><ul><li>Configuration Manager </li></ul></ul><ul><ul><li>Configuration Analyst </li></ul></ul><ul><ul><li>Configuration Librarian </li></ul></ul><ul><ul><li>CMS tools administrator </li></ul></ul>
  29. 33. <ul><li>What are we going to provide? </li></ul><ul><li>Can we afford it? </li></ul><ul><li>Can we provide enough of it? </li></ul><ul><li>How do we gain competitive advantage? </li></ul><ul><li>Perspective </li></ul><ul><ul><li>Vision, mission and strategic goals </li></ul></ul><ul><li>Position </li></ul><ul><li>Plan </li></ul><ul><li>Pattern </li></ul><ul><ul><li>Must fit organisational culture </li></ul></ul>
  30. 35. <ul><li>Resources </li></ul><ul><ul><li>Things you buy or pay for </li></ul></ul><ul><ul><li>IT Infrastructure, people, money </li></ul></ul><ul><ul><li>Tangible Assets </li></ul></ul><ul><li>Capabilities </li></ul><ul><ul><li>Things you grow </li></ul></ul><ul><ul><li>Ability to carry out an activity </li></ul></ul><ul><ul><li>Intangible assets </li></ul></ul><ul><ul><li>Transform resources into Services </li></ul></ul>
  31. 36. <ul><li>Prioritises and manages investments and resource allocation </li></ul><ul><li>Proposed services are properly assessed </li></ul><ul><ul><li>Business Case </li></ul></ul><ul><li>Existing Services Assessed . Outcomes: </li></ul><ul><ul><li>Replace </li></ul></ul><ul><ul><li>Rationalise </li></ul></ul><ul><ul><li>Renew </li></ul></ul><ul><ul><li>Retire </li></ul></ul>
  32. 37. Service Design <ul><li>How are we going to provide it? </li></ul><ul><li>How are we going to build it? </li></ul><ul><li>How are we going to test it? </li></ul><ul><li>How are we going to deploy it? </li></ul>
  33. 38. Processes in Service Design <ul><li>Availability Management </li></ul><ul><li>Capacity Management </li></ul><ul><li>ITSCM (disaster recovery) </li></ul><ul><li>Supplier Management </li></ul><ul><li>Service Level Management </li></ul><ul><li>Information Security Management </li></ul><ul><li>Service Catalogue Management </li></ul>
  34. 39. Service Level Management <ul><li>Service Level Agreement </li></ul><ul><ul><li>Operational Level Agreements </li></ul></ul><ul><ul><ul><li>Internal </li></ul></ul></ul><ul><ul><li>Underpinning Contracts </li></ul></ul><ul><ul><ul><li>External Organisation </li></ul></ul></ul><ul><ul><ul><li>Supplier Management </li></ul></ul></ul><ul><ul><li>Can be an annexe to a contract </li></ul></ul><ul><ul><li>Should be clear and fair and written in easy-to-understand, unambiguous language </li></ul></ul><ul><li>Success of SLM (KPIs) </li></ul><ul><ul><li>How many services have SLAs? </li></ul></ul><ul><ul><li>How does the number of breaches of SLA change over time (we hope it reduces!)? </li></ul></ul>
  35. 40. Things you might find in an SLA
  36. 41. Types of SLA <ul><li>Service-based </li></ul><ul><ul><li>All customers get same deal for same services </li></ul></ul><ul><li>Customer-based </li></ul><ul><ul><li>Different customers get different deal (and different cost) </li></ul></ul><ul><li>Multi-level </li></ul><ul><ul><li>These involve corporate, customer and service levels and avoid repetition </li></ul></ul>
  37. 42. Right Capacity, Right Time, Right Cost! <ul><li>This is capacity management </li></ul><ul><li>Balances Cost against Capacity so minimises costs while maintaining quality of service </li></ul>
  38. 43. Is it available? <ul><li>Ensure that IT services matches or exceeds agreed targets </li></ul><ul><li>Lots of Acronyms </li></ul><ul><ul><li>Mean Time Between Service Incidents </li></ul></ul><ul><ul><li>Mean Time Between Failures </li></ul></ul><ul><ul><li>Mean Time to Restore Service </li></ul></ul><ul><li>Resilience increases availability </li></ul><ul><ul><li>Service can remain functional even though one or more of its components have failed </li></ul></ul>
  39. 44. ITSCM – what? <ul><li>IT Service Continuity Management </li></ul><ul><li>Ensures resumption of services within agreed timescale </li></ul><ul><li>Business Impact Analysis informs decisions about resources </li></ul><ul><ul><li>E.g. Stock Exchange can’t afford 5 minutes downtime but 2 hours downtime probably wont badly affect a departmental accounts office or a college bursary </li></ul></ul>
  40. 45. Standby for liftoff... <ul><li>Cold </li></ul><ul><ul><li>Accommodation and environment ready but no IT equipment </li></ul></ul><ul><li>Warm </li></ul><ul><ul><li>As cold plus backup IT equipment to receive data </li></ul></ul><ul><li>Hot </li></ul><ul><ul><li>Full duplexing, redundancy and failover </li></ul></ul>
  41. 46. Information Security Management <ul><li>Confidentiality </li></ul><ul><ul><li>Making sure only those authorised can see data </li></ul></ul><ul><li>Integrity </li></ul><ul><ul><li>Making sure the data is accurate and not corrupted </li></ul></ul><ul><li>Availability </li></ul><ul><ul><li>Making sure data is supplied when it is requested </li></ul></ul>
  42. 47. Service Transition <ul><li>Build </li></ul><ul><li>Deployment </li></ul><ul><li>Testing </li></ul><ul><li>User acceptance </li></ul><ul><li>Bed-in </li></ul>
  43. 48. Good service transition <ul><li>Set customer expectations </li></ul><ul><li>Enable release integration </li></ul><ul><li>Reduce performance variation </li></ul><ul><li>Document and reduce known errors </li></ul><ul><li>Minimise risk </li></ul><ul><li>Ensure proper use of services </li></ul><ul><li>Some things excluded </li></ul><ul><ul><li>Swapping failed device </li></ul></ul><ul><ul><li>Adding new user </li></ul></ul><ul><ul><li>Installing standard software </li></ul></ul>
  44. 49. Knowledge management <ul><li>Vital to enabling the right information to be provided at the right place and the right time to the right person to enable informed decision </li></ul><ul><li>Stops data being locked away with individuals </li></ul><ul><li>Obvious organisational advantage </li></ul>
  45. 50. Data-Information-Knowledge-Wisdom Wisdom cannot be assisted by technology – it only comes with experience! Service Knowledge Information Management System is crucial to retaining this extremely valuable information
  46. 51. Service Asset and Configuration <ul><li>Managing these properly is key </li></ul><ul><li>Provides Logical Model of Infrastructure and Accurate Configuration information </li></ul><ul><li>Controls assets </li></ul><ul><li>Minimised costs </li></ul><ul><li>Enables proper change and release management </li></ul><ul><li>Speeds incident and problem resolution </li></ul>
  47. 52. Configuration Management System
  48. 53. BASELINE <ul><li>A Baseline is a “last known good configuration” </li></ul><ul><li>But the CMS will always be a “work in progress” and probably always out of date. </li></ul><ul><li>Current configuration will always be the most recent baseline plus any implemented approved changes </li></ul>
  49. 54. Change Management – or what we all get wrong! <ul><li>Respond to customers changing business requirements </li></ul><ul><li>Respond to business and IT requests for change that will align the services with the business needs </li></ul><ul><li>Roles </li></ul><ul><ul><li>Change Manager </li></ul></ul><ul><ul><li>Change Authority </li></ul></ul><ul><ul><ul><li>Change Advisory Board (CAB) </li></ul></ul></ul><ul><ul><ul><li>Emergency CAB (ECAB) </li></ul></ul></ul><ul><li>80% of service interruption is caused by operator error or poor change control (Gartner) </li></ul>
  50. 55. Change Types <ul><li>Normal </li></ul><ul><ul><li>Non-urgent, requires approval </li></ul></ul><ul><li>Standard </li></ul><ul><ul><li>Non-urgent, follows established path, no approval needed </li></ul></ul><ul><li>Emergency </li></ul><ul><ul><li>Requires approval but too urgent for normal procedure </li></ul></ul>
  51. 56. Change Advisory Board <ul><li>Change Manager (VITAL) </li></ul><ul><li>One or more of </li></ul><ul><ul><li>Customer/User </li></ul></ul><ul><ul><li>User Manager </li></ul></ul><ul><ul><li>Developer/Maintainer </li></ul></ul><ul><ul><li>Expert/Consultant </li></ul></ul><ul><ul><li>Contractor </li></ul></ul><ul><li>CAB considers the 7 R’s </li></ul><ul><ul><li>Who RAISED?, REASON, RETURN, RISKS, RESOURCES, RESPONSIBLE, RELATIONSHIPS to other changes </li></ul></ul>
  52. 57. Release Management <ul><li>Release is a collection of authorised and tested changes ready for deployment </li></ul><ul><li>A rollout introduces a release into the live environment </li></ul><ul><li>Full Release </li></ul><ul><ul><li>e.g. Office 2007 </li></ul></ul><ul><li>Delta (partial) release </li></ul><ul><ul><li>e.g. Windows Update </li></ul></ul><ul><li>Package </li></ul><ul><ul><li>e.g. Windows Service Pack </li></ul></ul>
  53. 58. Phased or Big Bang? <ul><li>Phased release is less painful but more work </li></ul><ul><li>Deployment can be manual or automatic </li></ul><ul><li>Automatic can be push or pull </li></ul><ul><li>Release Manager will produce a release policy </li></ul><ul><li>Release MUST be tested and NOT by the developer or the change instigator </li></ul>
  54. 59. Service Operation <ul><li>Maintenance </li></ul><ul><li>Management </li></ul><ul><li>Realises Strategic Objectives and is where the Value is seen </li></ul>
  55. 60. Processes in Service Operation <ul><li>Incident Management </li></ul><ul><li>Problem Management </li></ul><ul><li>Event Management </li></ul><ul><li>Request Fulfilment </li></ul><ul><li>Access Management </li></ul>
  56. 61. Functions in Service Operation <ul><li>Service Desk </li></ul><ul><li>Technical Management </li></ul><ul><li>IT Operations Management </li></ul><ul><li>Applications Management </li></ul>
  57. 62. Service Operation Balances
  58. 63. Incident Management <ul><li>Deals with unplanned interruptions to IT Services or reductions in their quality </li></ul><ul><li>Failure of a configuration item that has not impacted a service is also an incident (e.g. Disk in RAID failure) </li></ul><ul><li>Reported by: </li></ul><ul><ul><li>Users </li></ul></ul><ul><ul><li>Technical Staff </li></ul></ul><ul><ul><li>Monitoring Tools </li></ul></ul>
  59. 64. Event Management <ul><li>3 Types of events </li></ul><ul><ul><li>Information </li></ul></ul><ul><ul><li>Warning </li></ul></ul><ul><ul><li>Exception </li></ul></ul><ul><li>Can we give examples? </li></ul><ul><li>Need to make sense of events and have appropriate control actions planned and documented </li></ul>
  60. 65. Request Fulfilment <ul><li>Information, advice or a standard change </li></ul><ul><li>Should not be classed as Incidents or Changes </li></ul><ul><li>Can we give more examples? </li></ul>
  61. 66. Problem Management <ul><li>Aims to prevent problems and resulting incidents </li></ul><ul><li>Minimises impact of unavoidable incidents </li></ul><ul><li>Eliminates recurring incidents </li></ul><ul><li>Proactive Problem Management </li></ul><ul><ul><li>Identifies areas of potential weakness </li></ul></ul><ul><ul><li>Identifies workarounds </li></ul></ul><ul><li>Reactive Problem Management </li></ul><ul><ul><li>Indentifies underlying causes of incidents </li></ul></ul><ul><ul><li>Identifies changes to prevent recurrence </li></ul></ul>
  62. 67. Access Management <ul><li>Right things for right users at right time </li></ul><ul><li>Concepts </li></ul><ul><ul><li>Access </li></ul></ul><ul><ul><li>Identity (Authentication, AuthN) </li></ul></ul><ul><ul><li>Rights (Authorisation, AuthZ) </li></ul></ul><ul><ul><li>Service Group </li></ul></ul><ul><ul><li>Directory </li></ul></ul>
  63. 68. Service Desk <ul><li>Local, Central or Virtual </li></ul><ul><li>Examples? </li></ul><ul><li>Single point of contact </li></ul><ul><li>Skills for operators </li></ul><ul><ul><li>Customer Focus </li></ul></ul><ul><ul><li>Articulate </li></ul></ul><ul><ul><li>Interpersonal Skills (patient!) </li></ul></ul><ul><ul><li>Understand Business </li></ul></ul><ul><ul><li>Methodical/Analytical </li></ul></ul><ul><ul><li>Technical knowledge </li></ul></ul><ul><ul><li>Multi-lingual </li></ul></ul><ul><li>Service desk often seen as the bottom of the pile </li></ul><ul><ul><li>Bust most visible to customers so important to get right! </li></ul></ul>
  64. 69. Continual Service Improvement <ul><li>Focus on Process owners and Service Owners </li></ul><ul><li>Ensures that service management processes continue to support the business </li></ul><ul><li>Monitor and enhance Service Level Achievements </li></ul><ul><li>Plan – do –check – act (Deming) </li></ul>
  65. 70. Service Measurement <ul><li>Technology (components, MTBF etc) </li></ul><ul><li>Process (KPIs - Critical Success Factors) </li></ul><ul><li>Service (End-to end, e.g. Customer Satisfaction) </li></ul><ul><li>Why? </li></ul><ul><ul><li>Validation – Soundness of decisions </li></ul></ul><ul><ul><li>Direction – of future activities </li></ul></ul><ul><ul><li>Justify – provide factual evidence </li></ul></ul><ul><ul><li>Intervene – when changes or corrections are needed </li></ul></ul>
  66. 71. Benefits of ITIL Service Strategy <ul><li>Alignment of new & changing services to organizational strategy </li></ul><ul><li>Supports business cases for investment </li></ul><ul><li>Resolves conflicting demands for services </li></ul><ul><li>Improves service quality by strategic planning </li></ul><ul><li>Ensures that organizations can manage the costs and risks associated with their Service Portfolios </li></ul>
  67. 72. Benefits of ITIL Service Design <ul><li>Agreeing service level agreements with internal departments and external third party suppliers </li></ul><ul><li>Measuring IT quality in business terms </li></ul><ul><ul><li>Reduced total cost of ownership </li></ul></ul><ul><ul><li>Improved quality/consistency of service </li></ul></ul><ul><ul><li>Improved IT governance </li></ul></ul><ul><ul><li>More effective Service Management </li></ul></ul>
  68. 73. Benefits of ITIL Service Transition <ul><li>Align the new or changed service with the Organization’s requirements & business operations </li></ul><ul><li>Ability to adapt quickly to new service requirements </li></ul><ul><li>Improved success rate of changes </li></ul><ul><li>Improved organisational agility and flexibility </li></ul><ul><ul><li>Provides a consistent & rigorous framework for evaluating the service capability & risk before a new or changed service is released </li></ul></ul>
  69. 74. Benefits of ITIL Service Operation <ul><li>Delivering & managing services at agreed levels to Organizational customers & users </li></ul><ul><li>Management & monitoring of the technology that is used to deliver & support services </li></ul><ul><li>Management of Incidents, including Major Incidents, & ensuring recovery of service </li></ul><ul><li>Ensuring the appropriate IT organisation is in place to support the overall service requirements of the Organization </li></ul><ul><li>Cost-effective Service Delivery </li></ul>
  70. 75. Benefits of ITIL Continual Service Improvement <ul><li>Commitment to ongoing service quality </li></ul><ul><li>Ongoing improvements to service & supporting processes </li></ul><ul><li>Review & implementation of appropriate business-focused service measures </li></ul><ul><li>ROI (Return on Investment) </li></ul><ul><li>VOI (Value on Investment) </li></ul><ul><li>Continual improvement becomes part of “Business as Usual” </li></ul>
  71. 76. Change Management process explained in ITIL <ul><li>It is one of the most central and most important ITIL processes </li></ul><ul><li>Everything that changes a status in a CI in CMDB in ITIL </li></ul><ul><li>Change mgr should have a good broad overview, some in-depth knowlegde in key areas, and know lots of the local history. </li></ul>
  72. 77. Relationship to other processes Change mgmt Release mgmt Config. mgmt Problem mgmt Incident mgmt Capacity mgmt Availability mgmt IT service cont mgmt Service level mgmt
  73. 78. Goal <ul><li>Ensure that all changes are performed in a structured , documented and well-planned process. </li></ul><ul><li>Balance between flexibility (what needs to be done right now) and stability (so that changes does not break anything. </li></ul>
  74. 79. Rôles <ul><li>Change manager </li></ul><ul><li>Change coordinator </li></ul><ul><li>Change Advisory Board (CAB) </li></ul><ul><ul><li>Change mgr, Service Level mgr, repr/service desk, repr/problem mgmt, management, business rep, user reps, development rep, system administrators, vendor reps. </li></ul></ul><ul><li>CAB/Emergency Commitee (CAB/EC) </li></ul><ul><ul><li>Only the most essential members of CAB. </li></ul></ul>
  75. 80. Activities RFC submission, Recording Acceptance; filtering RFCs Configuration mgmt processes info and monitors the status of CIs Classification, category and priority Urgent? Planning; Impact and Resources Coordination Build Test Implement Working Evaluation and Close Rejection, possibly new RFC Start back-out plan Urgent procedures Yes No
  76. 81. Registration of an RFC <ul><li>Identification number </li></ul><ul><li>References to problems and known errors </li></ul><ul><li>Description and references to CIs involved </li></ul><ul><li>Rationale for the change </li></ul><ul><li>Current and future CIs that will be changed </li></ul><ul><li>Name and contact info for the person that suggested the RFC </li></ul><ul><li>Date etc </li></ul><ul><li>Overview of resource usage and time estimates </li></ul>
  77. 82. Acceptance <ul><li>The process of accepting an RFC, has as its goal to filter out proposed changes that are incomplete, impractival, impossible, too expensive, unclear, that is untimely (must wait to a better time), or that has unwanted consequences. </li></ul>
  78. 83. Further information in an RFC <ul><li>Data on categorization and priority </li></ul><ul><li>Estimate on how it will affect the rest of the system </li></ul><ul><li>Recommendations from change mgr </li></ul><ul><li>History of the handling of this RFC, including acceptance and autorization </li></ul><ul><li>Plans for backup </li></ul><ul><li>Requirements for maintenance </li></ul><ul><li>Plan for implementation </li></ul><ul><li>Roles for the implementation phase, including casts </li></ul><ul><li>Timing for the implementation </li></ul><ul><li>Timing for evaluation </li></ul><ul><li>Test results and observed problems </li></ul><ul><li>If the change is rejected, a reason why </li></ul><ul><li>Information on scenarios and evaluation </li></ul>
  79. 84. Classification <ul><li>Priority: </li></ul><ul><li>Low (postponable) </li></ul><ul><li>Normal </li></ul><ul><li>High </li></ul><ul><li>Urgent (must do now) </li></ul><ul><li>Categories </li></ul><ul><li>Low impact </li></ul><ul><li>Significant impact </li></ul><ul><li>Great impact </li></ul>
  80. 85. Planning and Acceptance <ul><li>Three levels of acceptance: </li></ul><ul><li>Financial (can we afford this? Cost/benefit?) </li></ul><ul><li>Technical (is it doable and is it smart to do it?) </li></ul><ul><li>Business (is it constructive compared to focus of what we do as an organization?) </li></ul><ul><li>Forward Schedule of Change (FSC): overview over future, planned changes </li></ul><ul><li>CAB should discuss: </li></ul><ul><ul><li>Unautorized changes </li></ul></ul><ul><ul><li>Autorized changes that shortcut the CAB </li></ul></ul><ul><ul><li>RFCs for review in CAB </li></ul></ul><ul><ul><li>Changes that is open or that was recently closed. </li></ul></ul><ul><ul><li>Review of changes that have been implemented. </li></ul></ul>
  81. 86. Coordination <ul><li>Key notions: </li></ul><ul><li>Iterative process </li></ul><ul><li>Should be tested in a laboratory </li></ul><ul><li>Holistic view: SW, HW, docs, procedures etc… </li></ul><ul><li>RFC is the plan that controls the changes </li></ul><ul><li>No change without a RFC </li></ul>Build Test Implement
  82. 87. Evaluation <ul><li>There should be a Post-implementation Review (PIR) after the completion of the change. </li></ul><ul><li>This must be governed by the CAB. </li></ul><ul><li>Was the goals for the change achieved ? </li></ul><ul><li>What is (if relevant) the satisfaction of the users ? </li></ul><ul><li>Was any side effects discovered after this change? </li></ul><ul><li>Was the change on budget and on time ? </li></ul><ul><li>Are there any points to follow up? </li></ul>
  83. 88. Standard changes <ul><li>For small , structured, frequent, trivial and easily understandable changes, it is possible to give acceptance in advance – as a standard change. </li></ul><ul><li>Std chg are like templates or procedures which are to be used in certain, predefined situations with-out further process. </li></ul><ul><li>Std chg must be logged, but Change mgr is not involved in each specific case. </li></ul>
  84. 89. Emergency changes <ul><li>If absolutely necessary, every non-essential, non-technical stage can be circumvented … </li></ul><ul><li>… but the procedures for such must be defined for the organization in advance : </li></ul><ul><ul><li>CAB/EC is a sub-set of CAB and it is easier to arrange for a meeting </li></ul></ul><ul><ul><li>Change mgr can make decisions by himself </li></ul></ul><ul><ul><li>Testing, documentation etc can be done post factum. </li></ul></ul><ul><li>Important: all shortcuts must be evaluated afterwards. </li></ul>
  85. 90. Reporting <ul><li>Reports : </li></ul><ul><li>Number of changes pr time unit and pr CI </li></ul><ul><li>Overview of origin for changes and RFCs </li></ul><ul><li>No of successful changes </li></ul><ul><li>No of back-outs </li></ul><ul><li>No of incidents that can be related to changes </li></ul><ul><li>Graphs and trends </li></ul><ul><li>Performance indicators : </li></ul><ul><li>No of changes pr time unit. </li></ul><ul><li>Avg time to perform a change </li></ul><ul><li>No of rejected changes </li></ul><ul><li>No of incidents that can be related to changes </li></ul><ul><li>No of back-outs </li></ul><ul><li>Costs related to changes </li></ul><ul><li>Share of changes that is within time and budget </li></ul>
  86. 91. Input and output Change mgmt RFC CMDB FSC (forward schedule of change) FSC History Reports Triggers for other proc
  87. 92. Helpdesk IT-sysadmin- staff Customers Single point of entry E-mail Physical access Telephone Web Chat Porjects Interrupt- controlled
  88. 93. <ul><li>To maintain control over the speed </li></ul><ul><li>To make things more uniform for the users </li></ul><ul><li>To prioritize between different tasks </li></ul><ul><li>To get an overview over which tasks remains </li></ul><ul><li>To limit interruptions to a small part of the organization </li></ul><ul><li>Centralize expertize on user communication </li></ul>
  89. 94. <ul><li>Not everybody is suitable for work there … </li></ul><ul><li>Consider interior and location </li></ul><ul><li>Estimate sufficient staffing </li></ul><ul><li>Announce it actively, target user groups </li></ul><ul><li>Monitor it for performance </li></ul><ul><li>Use relevant tools to support the helpdesk </li></ul>
  90. 95. <ul><li>If we stopped caring about the customers, maybe they would stop bothering us? </li></ul>
  91. 96. <ul><li>Location </li></ul><ul><ul><li>An area where lots of people pass by </li></ul></ul><ul><ul><li>Preferably a neutral area </li></ul></ul><ul><li>Interior : </li></ul><ul><ul><li>Sufficient room (space and air) </li></ul></ul><ul><ul><li>Friendly colors and furniture </li></ul></ul><ul><ul><li>No ’hang-arounds ’, ’old friends’ or ’pentioneers’ </li></ul></ul>
  92. 97. <ul><li>Ratio between helpdesk staff and users depends on the situation: </li></ul><ul><li>University environment (emploees): 50-100 </li></ul><ul><li>Students: 300-2000 </li></ul><ul><li>ISP: 5000-50000 </li></ul><ul><li>Note: these numbers are only examples (and they change all the time) </li></ul>
  93. 98. “ Nobody” read the documentation Docs must be Especially designed Location Timing Repetition Variation Focus Briefness Comprehensible Relevance & Usefulness
  94. 99. <ul><li>Number of customers by helpdesk staffer </li></ul><ul><li>Volume of contact, and the change over time to this volume </li></ul><ul><li>Degree of fulfillment of SLA </li></ul><ul><li>Need for personalized training and education </li></ul><ul><li>Share of incidents that is escalated </li></ul>
  95. 100. Problem Symptom Error message First feedback Analysis Fixing Final feedback Closure 1 minute 10 minutes 1 hour Note: the times given is just examples for discussion
  96. 101. <ul><li>Priority </li></ul><ul><li>Ownership </li></ul><ul><li>Contact-info and customer info </li></ul><ul><li>Timestamps </li></ul><ul><li>Refs to CIs </li></ul><ul><li>Status </li></ul><ul><li>Categorizations </li></ul><ul><li>History </li></ul><ul><li>Connect similar cases </li></ul><ul><li>Close old cases </li></ul><ul><li>Dispatch cases </li></ul><ul><li>Make statistics </li></ul><ul><li>Search in old cases </li></ul><ul><li>Prioritize between cases </li></ul><ul><li>Escalate cases </li></ul>
  97. 102. <ul><li>Coverage – How many are covered by the error (1 – 5 – 100 – all)? </li></ul><ul><li>Severity – what is the consequence if the error is not corrected (beauty-error – inconvenience – error – crisis)? </li></ul><ul><li>Frequency – how often does this error ocurr? (continually – daily – monthly – once)? </li></ul><ul><li>Status – how important is the reporter of the error (your boss -- paying – non-paying) </li></ul>
  98. 103. New Open More info Archived Closed Wait In work Analysed
  99. 104. <ul><li>Which machines and applications </li></ul><ul><li>Who can contact the helpdesk </li></ul><ul><li>Where can they get help </li></ul><ul><li>When can they get help </li></ul><ul><li>How long must they expect to wait </li></ul><ul><li>How is the incident escalated </li></ul>
  100. 105. Welcome Problem identification Planning and execution Verification Greet them Classification Description Verification Alternatives Selection a Solution Implementation By sysadmin By user Closure
  101. 106. <ul><li>This phase is often under-estimated (But, it is just a nice ’hello’) </li></ul><ul><li>It is often a critical phase – it is a first impression, and some users can easily feel dismissed. </li></ul><ul><li>If done well, it will facilitate the next message from that user. </li></ul>
  102. 107. <ul><li>Classification – which area is this problem within. Might be partly automatic </li></ul><ul><li>Description – Make a short and explicit description of the incident, </li></ul><ul><li>Verification – check that the problem is reproducible </li></ul>
  103. 108. <ul><li>Suggest different solutions – maybe on temporary for ’today’ and a possible permanent for the future. Often a task for experts </li></ul><ul><li>Select a solution – prioritize between the solutions, involve the user, and a suitable solution. </li></ul><ul><li>Execution – let a sysadmin execute the solution if neccessary, or otherwise help the user </li></ul>
  104. 109. <ul><li>Sysadm-verification – Let those who have changed something or suggested a solution test it before forwarding it to the user </li></ul><ul><li>User-verification – Let the user himself test the solution, and come with feedback on whether the solution worked or not. </li></ul>
  105. 110. <ul><li>The bogeyman – frightens the user away … no work </li></ul><ul><li>The forwarder – sends the user somewhere else </li></ul><ul><li>The assumptionist – knows what the problem is, even without having studied the problem and symptoms </li></ul><ul><li>The conceptualist – who fixes minor things by changing ’everything’ </li></ul><ul><li>The typo-ist – who never is able to write docs, commands, or scripts without typos. </li></ul><ul><li>Hit-and-run-Sysadm – comes, writes commands, runs (doesn’t tests) </li></ul><ul><li>The Sandman – closes ticket – nice and quetly </li></ul>
  106. 111. <ul><li>The Benefits of ITSM </li></ul><ul><li>Cut IT costs </li></ul><ul><li>Streamline IT support through automation of processes </li></ul><ul><li>Optimize resource usage through better visibility and planning </li></ul><ul><li>Measure, monitor and reduce cost of service provision </li></ul><ul><li>Maximize productivity and customer retention through better services and support </li></ul><ul><li>External IT support is more responsive and consistent, increasing customer satisfaction and retention </li></ul><ul><li>Internal IT support is more effective, keeping business users productive and increasing capacity to generate revenue </li></ul><ul><li>Gain a competitive edge through increased agility </li></ul><ul><li>Become more responsive to the needs of the business </li></ul><ul><li>Streamline IT support and drive a transformation from reactive to proactive IT </li></ul><ul><li>Take new lines of business to market quicker through faster delivery of supporting IT services </li></ul><ul><li>Mitigate risk and ensure business continuity </li></ul><ul><li>Plan changes and assess impact </li></ul><ul><li>Escalate decision-making to management </li></ul>
  107. 112. Conclusions and recommendations <ul><li>ITIL is an enabler for process improvement </li></ul><ul><li>A combination of processes/people/tools is required </li></ul><ul><li>Only tools can provide effective automation </li></ul><ul><li>The tool investments will generate ROI, not the “ITIL project” </li></ul><ul><li>Always measure your progress by measuring before and after process improvements </li></ul><ul><li>IT process planning tool — other departments may already have a tool to plan/measure business processes </li></ul>
  108. 113. ITIL v3 Certification Roadmap
  109. 114. Thank You